From owner-cvs-all Sat Jul 4 11:58:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA27335 for cvs-all-outgoing; Sat, 4 Jul 1998 11:58:19 -0700 (PDT) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA27323; Sat, 4 Jul 1998 11:58:15 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id LAA26294; Sat, 4 Jul 1998 11:54:03 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd026275; Sat Jul 4 18:53:59 1998 Date: Sat, 4 Jul 1998 11:53:53 -0700 (PDT) From: Julian Elischer To: Bruce Evans cc: cvs-committers@FreeBSD.ORG, julian@FreeBSD.ORG Subject: Re: cvs commit: src/sys/dev/vn vn.c In-Reply-To: <199807040841.SAA31111@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk 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