Re: tuning FFS for large files Re: A specific example of a disk i/o problem

[Bruce Evans]

On Mon, 5 Oct 2009, Dieter wrote:

I found a clue!  The problem occurs with my big data partitions,
which are newfs-ed with options intended to improve things.

Reading a large file from the normal ad4s5b partition only delays other
commands slightly, as expected.  Reading a large file from the tuned
ad4s11 partition yields the delay of minutes for other i/o.
...
Here is the newfs command used for creating large data partitions:
newfs -e 57984 -b 65536 -f 8192 -g 67108864 -h 16 -i 67108864 -U -o time 
$partition

Any block size above the default (16K) tends to thrash and fragment buffer
cache virtual memory.  This is obviously a good pessimization with lots of
small files, and apparently, as you have found, it is a good pessimization
with a few large files too.  I think severe fragmentation can easily take
several seconds to recover from.  The worst case for causing fragmentaion 
is probably a mixture of small and large files.

Some users fear fs consistency bugs with block sizes >= 16K, but I've never
seen them cause any bugs ecept performance ones.

Even this isn't tuned the way I wanted to.
-g * -h must be less than 4 G due to 32 bit problem (system panics).

The panic is now avoided in some versions of FreeBSD (-8 and -current at
least).

Note the 32 bit problem is in the filesystem code, I'm running amd64.
IIRC there is a PR about this.  (I'm assuming the bug hasn't been fixed yet)
Result is that I must specify -g and -h smaller than they should be.

I bet you can't see any difference (except the panic) from enlarging -g and
-h.

And they have way more inodes than needed. (IIRC it doesn't actually
use -i 67108864)

It has to have at least 1 inode per cg, and may as well have a full block
of them, which gives a fairly large number of inodes especially if the
block size is too large (64K), so the -i ratio is limited.

Bruce
_______________________________________________
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"