Messages in this thread | | | Date | Fri, 25 Jun 1999 13:01:53 +0300 | From | Matti Aarnio <> | Subject | Re: why is the size of a directory always 1024b ? |
| |
Aw, come on... MINOR downtime required, doable even in multiuser mode! (story in series of 'how did I move 100 000+ customers from flat directory to hashed trees in live system early in the morning..')
On Fri, Jun 25, 1999 at 04:45:27PM +0800, David Luyer wrote: > A real example where this isn't possible; .... > oh look, /usr/users is still big and horribly slow for some operations. > and the only way to fix it is to either build a second raid array of the > same size or to delete everything and restore from backups, since you need > to mkfs to clean up the mount point directory being bloated. > > major downtime required to get decent performance.
For most lookup cases having monsterously large directory data space doesn't hurt, if all your named objects are at the BEGINNING of that space. That is what you want to ensure:
# cd /usr/users # mkdir .zzz # mv * .zzz # mv .zzz/* . # rmdir .zzz
(This assumes you don't have extra dot-files in there, and this will also qsort() those file/directory names.)
> Not good. There has to be a better way of doing this. Personally I'd prefer > a magic option to fsck to tell it to compact directories which are more than > X% wasted space before you mount them.
Yes, even better; could also sort() names in directories at the same time.. But likely the BTREE directories will do this, too. Ted ?
> David.
/Matti Aarnio <matti.aarnio@sonera.fi>
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |