Date: Tue, 18 Apr 2000 17:46:11 +0800 From: Adrian Chadd <adrian@freebsd.org> To: Dave Chapeskie <dchapes@borderware.com> Cc: Adrian Chadd <adrian@freebsd.org>, Matthew Dillon <dillon@apollo.backplane.com>, freebsd-fs@freebsd.org Subject: Re: vnode_free_list corruption [patch] Message-ID: <20000418174608.C71428@ewok.creative.net.au> In-Reply-To: <00Apr17.185117edt.117127@gateway.borderware.com>; from Dave Chapeskie on Mon, Apr 17, 2000 at 06:54:20PM -0400 References: <00Apr14.141908edt.117140@gateway.borderware.com> <20000415023148.F34852@ewok.creative.net.au> <200004141835.LAA71253@apollo.backplane.com> <20000418042733.I59015@ewok.creative.net.au> <00Apr17.185117edt.117127@gateway.borderware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 17, 2000, Dave Chapeskie wrote: > By the way, thanks for looking into this! > > On Tue, Apr 18, 2000 at 04:27:35AM +0800, Adrian Chadd wrote: > > Ok, my take on the code is this: > > > > * with the trace given, the vnode shouldn't even be marked VDOOMED, as its > > meant to be in use, > > * a vnode shouldn't ever reach vbusy when marked VDOOMED, as it should be > > ref/held and so shouldn't ever be considered to be cleaned, > > * I think a KASSERT should be added in vbusy() > > Since the situation is known to happen, at least I know it does :-), > I think it should be a real call to panic as in my patch instead of a > KASSERT that is only enabled if options INVARIANTS is used. If the > system is fixed to prevent this situation then it can always be changed > to a KASSERT (if the quick check of the flag is too slow for people). Yes, but from my take of the code, if a vnode reaches VDOOMED, its been earmarked for recycling and is in the process of being flushed. If the vnode is being used in the FS code somewhere (or anywhere for that matter :) it shouldn't ever be considered for recycling as it should be vref()'ed or at the least vhold()'ed. > > On my machine (400Mhz Celeron, 64mb RAM, single 4.2gig IDE disk) running > > current from a day ago, I can't reproduce the bug. Are you running with > > multiple spindles/softupdates ? > > Since I was able to reproduce it on machines with very different CPUs, > memory, and disks I didn't bother to include machine specifications. > The customers that were seeing the problem most often are running "high > end" (whatever that means) machines with SCSI disks. The machine I used > for testing was a 200 MHz Pentium machine with IDE disks. Softupdates > was never enabled on any of these systems. > > Here is the dmesg output for the machine I did most of my testing on, > only partitions on wd2 were mounted during the tests. On my workstation > with 64MB of RAM it took much longer to happen and I had some other > processes consuming memory, so it might be easier for you to reproduce > it if you lower your available system memory to 32 MB or less (via > MAXMEM or the boot loader of course). Right, I'll drop MAXMEM down and try to starve the system further, and see what happens. Adrian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000418174608.C71428>