[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.019 / U:8.480 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site