On Tue, Jan 15, 2013 at 10:03:50PM -0800, Linda Walsh wrote:
> Was doing some createrepo ops with about 3k rpms and it created a
> cachedir w/~10k LONG entries .. size of the dir was(is) 348k,
> did a frag count on it and it had 155 fragments. Ouch.
> Tried to make a copy w/links thinking that doing so might create all
> the names "quickly enough" (?!) to benefit from some block-allocation
> coalescing. Not at all ;-(.
> Anyway to pre-alloc a dir or some means get a dir w/fewer frags...
> Mostly curiosity -- though I'd fix it if there was an easy fix -- but
> it's not a dir that's going to get much access, so it doesn't matter
Just because the directory has lots of extents, it doesn't
mean it is fragmented. Indeed, the directory read order may be a
different order to the order of extents, especially as tehre are
multiple trees/indexes in the directory structure that are used
depending on the type of access. So unless you have a performance
problem, there is nothing to "fix". And if you do have a perf
problem with large directories, then use a larger directory block