Date: Sat, 22 Sep 2001 11:07:33 -0700 (PDT)
From: Matt Dillon <dillon@earth.backplane.com>
To: Joe Greco <jgreco@ns.sol.net>
Cc: freebsd-stable@FreeBSD.ORG, chuck@research.att.com
Subject: Re: 4.4-RELEASE kernel deadlock ("FFS node")
Message-ID: <200109221807.f8MI7X681131@earth.backplane.com>
References: <200109220402.XAA34985@aurora.sol.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Basically the buffer cache reserves 16K of KVM per buffer. It is
possible to allocate larger buffers, but if you create a filesystem
with a block size greater then 16384 you put all sorts of stress on
the buffer cache code which could lead to problems such as memory
fragmentation of the buffer cache KVA space. I don't know of
any problems that would cause a system crash, but we just haven't tested
the case well enough to be able to say that block sizes greater then
16384 are reliable.
-Matt
:> the one unusual thing about the configuration is that the filesystem
:> we are attempting to build on is a 136GB ccd across 4 scsi disks with
:> the fsize=8192 and the bsize=65536 (it is mainly to be used for large
:> data log files):
:
:FreeBSD doesn't support fsize/bsize so large. There are ongoing issues
:within the filesystem code and VM code that will cause such filesystems
:to break under heavy load. Matt Dillon also talked about this being less-
:than-optimal for the VM system from some technical points of view. I ran
:into this years ago, and have been content to live with
:
:newfs -c 96 -b 16384 -f 4096 -i 1048576 /dev/rccd${i}e
:
:on filesystems weighing in at 576GB. Note that this is also for very
:large file storage (see -i) and I'd love to use a larger -b/-f (and then
:a larger -c) but so far nobody's cared enough to do anything about it, and
:I have neither the kernel skills nor the time to look at it, since in
:reality the values above work fine and the only noticeable side effect is
:that the fsck goes a bit slower.
:
:I ran into problems with -b 32768 -f 8192 as well. I didn't attempt all
:combinations of options, though, since for my application, lockups were a
:bit random due to the light amount of use involved.
:--
:Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
:"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
:won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
:With 24 million small businesses in the US alone, that's way too many apples.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200109221807.f8MI7X681131>