[lkml]   [1999]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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 <>

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:52    [W:0.053 / U:3.292 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site