Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!spool.mu.edu!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: 26 Oct 93 12:34:14
Organization: Kernel Hackers 'r' Us
Lines: 34
Message-ID: <CGD.93Oct26123414@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.
first of all, it is incorrect of the sysad to specify a FS block size
of more than MAXBSIZE. that is almost enough of an answer for me.
Further ramblings on the topic:
NetBSD-current's vfs_bio is written in such a way that it 'does the
right thing' with respect to resizing buffers, and having arbitrary
numbers of buffers with arbitrary numbers of pages each.
Because of this, it's 'safe' for us to increase MAXBSIZE, which we
might do.
unfortunately, there's no way for the buffer cache to return an error
in the case where a buffer request _cannot ever_ be satisfied.
I'm going to chalk this one up as 'user configuration error',
and have the kernel panic.
>Consider this a bug report. :-)
don't post bug reports, mail them.
chris
--
chris g. demetriou cgd@cs.berkeley.edu
smarter than your average clam.