Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!agate.berkeley.edu!cgd
From: cgd@eden.CS.Berkeley.EDU (Chris G. Demetriou)
Newsgroups: comp.os.386bsd.questions
Subject: Re: [BUG?] newfs with bsize = 16 kb ?
Date: 27 Oct 93 23:22:27
Organization: Kernel Hackers 'r' Us
Lines: 45
Message-ID: <CGD.93Oct27232227@eden.CS.Berkeley.EDU>
References: <1993Oct23.193511.18122@Informatik.TU-Muenchen.DE> <2agbtr$5v0@Germany.EU.net>
<NEWSSERV!STARK!GENE.93Oct25153858@stark.uucp>
<CFI5oM.n3u@flatlin.ka.sub.org>
NNTP-Posting-Host: eden.cs.berkeley.edu
In-reply-to: bad@flatlin.ka.sub.org's message of Tue, 26 Oct 1993 11:38:45 GMT
In article <CFI5oM.n3u@flatlin.ka.sub.org> bad@flatlin.ka.sub.org (Christoph Badura) writes:
The answer as to why a blocksize larger than MAXBSIZE trashes system
memory is that in NetBSD0.9 the routines in vfs_bio.c make no attempt
whatsoever to prevent the allocation of a buffer greater than
MAXBSIZE but will not allocate more than MAXBSIZE of memory to the
buffer.
i've just reviewed the 0.9 code, to check some things out.
basically:
(1) if something tries to allocate a buffer > MAXBSIZE in size,
it's an internal error and there should be a panic;
this is a bug, that is fixed in -current, but because of
(2) and (3) it should not have been a problem.
(2) the only conditions under which this will happen are
when a file system with a block size > MAXBSIZE
is mounted. this cannot happen assuming that the kernel
was compiled correctly, because UFS refuses to mount
a file system with block size > MAXBSIZE
(3) the vfs_bio in 0.9 WAS flexible enough to accomodate varying
values of MAXBSIZE.
therefore, my conclusions:
(a) if a person saw this bug under 0.9, it was most likely because
he/she tried to recompile the kernel with a different-than-
normal MAXBSIZE, and did not recompile it completely.
(b) if the person saw it under something other than NetBSD 0.9
(i.e. FreeBSD, 386bsd, or NetBSD 0.8), then all bets
are off.
as previously noted, NetBSD has a complete and working buffer cache,
and so we'll probably be bumping up MAXBSIZE to 16k in the next release.
(to do so previously would have incurred a large performance penaltly,
because *all* buffers under 0.9 are MAXBSIZE, which is obviously a
memory hit if you've got all 8k file systems...)
chris
--
chris g. demetriou cgd@cs.berkeley.edu
smarter than your average clam.