Date: Tue, 12 Oct 2004 14:40:02 -0400 From: Mikhail Teterin <Mikhail.Teterin@murex.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: bde@zeta.org.au Subject: Re: panic in ffs (Re: hangs in nbufkv) Message-ID: <416C2502.5040505@murex.com> In-Reply-To: <200410121818.i9CIIGRx092072@apollo.backplane.com> References: <416AE7D7.3030502@murex.com> <200410112038.i9BKcCWt051290@apollo.backplane.com> <416C1B10.7030103@murex.com> <200410121818.i9CIIGRx092072@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote:
> Well, it's possible that UFS has bugs related to large block sizes.
> People have gotten bitten on and off over the years but usually it
> works ok if you leave the 8:1 blocksize:fragsize ratio intact. e.g.
> if you have a 64KB block size then you should use a 8K frag size.
> If you have a 32KB block size then you should use a 4K frag size.
>
>
This is the case here: fs_bsize 65536, fs_fsize 8192.
> I think the buffer cache itself is is likely not the source of this
> particular bug.
>
>
I don't know, how, but the bug seems triggered by upping the
net.inet.udp.maxdgram from 9216 (default) to 16384 (to match the NFS
client's wsize). Once I do that, the machine will either panic or just
hang a few minutes into the heavy NFS writing (Sybase database dumps
from a Solaris server). Happened twice already...
-mi
P.S. Thanks for prompt responses and advice, BTW!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?416C2502.5040505>