From owner-freebsd-stable Sat Sep 22 11: 7:51 2001 Delivered-To: freebsd-stable@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 4792637B40F for ; Sat, 22 Sep 2001 11:07:45 -0700 (PDT) Received: (from dillon@localhost) by earth.backplane.com (8.11.6/8.11.2) id f8MI7X681131; Sat, 22 Sep 2001 11:07:33 -0700 (PDT) (envelope-from dillon) Date: Sat, 22 Sep 2001 11:07:33 -0700 (PDT) From: Matt Dillon Message-Id: <200109221807.f8MI7X681131@earth.backplane.com> To: Joe Greco Cc: freebsd-stable@FreeBSD.ORG, chuck@research.att.com Subject: Re: 4.4-RELEASE kernel deadlock ("FFS node") References: <200109220402.XAA34985@aurora.sol.net> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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