Long ago (10-15 internet-years ago..) I followed testing of
FFS-family of filesystems in Squid cache.
We noticed at Solaris machines using UFS, than when the directory
data size grew above the number of blocks directly addressable by
the direct-index pointers in the i-node, system speed plummeted.
(Or perhaps it was something a bit smaller, like 32 kB)
Consider: 4 kB block size, 12 direct indexes: 48 kB directory size.
Spend 16 bytes for each file name + auxiliary data: 3000 files/subdirs
Optimal would be to store the files inside only the first block,
e.g. the directory shall not grow over 4k (or 1k, or ..)
Name subdirs as: 00 thru 7F (128+2, 12 bytes ?)
Possibly do that in 2 layers: 128^2 = 16384 subdirs, each
with 50 long named users (even more files?): 820 000 users.
Tune the subdir hashing function to suit your application, and
you should be happy.
Putting all your eggs in one basket (files in one directory)
is not a smart thing.
> Alan
/Matti Aarnio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/