Date: Sat, 4 Jul 1998 11:53:53 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: Bruce Evans <bde@zeta.org.au> Cc: cvs-committers@FreeBSD.ORG, julian@FreeBSD.ORG Subject: Re: cvs commit: src/sys/dev/vn vn.c Message-ID: <Pine.BSF.3.95.980704114625.10069C-100000@current1.whistle.com> In-Reply-To: <199807040841.SAA31111@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 4 Jul 1998, Bruce Evans wrote: > > Modified files: > > sys/dev/vn vn.c > > Log: > > Don't use a struct buf (malloc'd) without first initialising all the fields > > to some known value! > > (probable cause of soft updates exploding with vn devices) > > Buffers should never be malloced. There is no way of knowing how to > initialize new fields like b_dep. geteblk() should always work, but > might be a bit slow. vfs_cluster.c uses trypbuf(). I agree, however that is a bigger problem than I was trying to solve. The original fix was just to add the initialisation of b_dep, but I thought that if new fields are added it might be a god idea to make sure that they are at least cleared. The correct fix is to figure out why the original authour used malloc, and if it isn't a GOOD reason, switch to using geteblk() > This is not quite > suitable for vn, since trypbuf() can fail. This is not quite suitable > for clustering, since trypbuf can fail :-) (it's fairly easy (1) to use > all pbufs doing a singly iozone when the ratio buf/nswbuf is large (2), > and then clustering doesn't cluster). > > I don't like mixing bzero() with explicit initialization of all the > necessary fields. vn previously attempted to initialize them all. > The bzero() bogotifies all the explicit initializations to 0. I plane to look around this code, and try figure out a better fix but this stops the crashes, which, after all is a more important criteria than "it makes other code redundant". > > (1) The dirty buffers watermarks don't work when there is lots of > clustering. Dirty normal buffers are converted to non-dirty > normal buffers and dirty pbufs, so processes like iozone aren't > limited by the watermarks until clustering breaks down. > > (2) nswbuf is clamped to a fairly small value, while nbuf is clamped > to a relatively large value. All true.. Any suggestions? > > Bruce > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.980704114625.10069C-100000>