Mike Meyer wrote:
This seems very reasonable. The trick is figuring out what "the median
file size" is. I grabbed my mail archive, but that's unlikely to be
representative of most users. You either need to guess right, or make
arrangements to reformat the file system using current dasa at regular
intervals.
Sorry if I wasn't explicit enough. I was suggesting that the user who
submitted the original message actually measure this, and then yes, a
newfs'ing of the file system will be necessary. Or you could of course
create a new data disk, formatted to fit your specs, then copy the data
over, etc.
Taking Doug's suggestion into account, and using the data I had, the
correct answer would be an 8K/1K file system, possibly with "-i 2048" to
double the number of inodes.
I'm not convinced that increasing the number of inodes in this way would be
the right way to go. The default is 4*<frag-size>, which is usually pretty
reasonable. I imagine (although it's impossible to state conclusively
without seeing the files), that the inode problem is a symptom, and that
tuning the block size will fix the real problem.
However, I did see an interesting possibility. What do you do if the
median file size is, for example, 4.1K?
You make the block size 8k.
A 4K block won't hold your median file. But an 8K block wastes a lot of
space. You might get a file with 0 blocks and 3 frags, assuming that UFS2
will do that, which doesn't seem good. If UFS2 won't do that, you get a
lot of half-empty blocks, which likewise isn't good. The other option is
a 4K block size, which means you get a lot of 1 block + 1 frag files.
That seems optimal in this case.
That's a logical analysis, but you're missing one important premise. UFS
doesn't do "more than one file per frag" until the file system gets close to
filling up, and the optimization switches from time to space. Therefore, in
your example you're actually wasting more space than you would with 8k
blocks, and as a side effect making the fs less efficient in at least 2 ways.
hth,
Doug
--
This .signature sanitized for your protection
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
