From owner-freebsd-fs Sun Apr 9 0:57: 6 2000 Delivered-To: freebsd-fs@freebsd.org Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by hub.freebsd.org (Postfix) with ESMTP id A684737B700; Sun, 9 Apr 2000 00:57:03 -0700 (PDT) (envelope-from ezk@shekel.mcl.cs.columbia.edu) Received: from shekel.mcl.cs.columbia.edu (shekel.mcl.cs.columbia.edu [128.59.18.15]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id DAA01574; Sun, 9 Apr 2000 03:56:57 -0400 (EDT) Received: (from ezk@localhost) by shekel.mcl.cs.columbia.edu (8.9.3/8.9.3) id DAA29145; Sun, 9 Apr 2000 03:56:57 -0400 (EDT) Date: Sun, 9 Apr 2000 03:56:57 -0400 (EDT) Message-Id: <200004090756.DAA29145@shekel.mcl.cs.columbia.edu> From: Erez Zadok To: Kris Kennaway Cc: John Estess , adrian@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG, freebsd@unix-consult.org Subject: Re: UNIONFS In-reply-to: Your message of "Sat, 08 Apr 2000 14:08:57 PDT." Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message , Kris Kennaway writes: > On Sat, 8 Apr 2000, John Estess wrote: > > > I've perused the mailing lists for the union fs and read the scant info > > in the D&I book, but I want to make sure there isn't a RFC or something > > for this fs. Is there some guidance besides the source code for this > > thing or is this a "let your conscience be your guide" scenario? > > There's no RFC, since it's not an internet service :-) What would be > useful in understanding what's going on are the papers by John Heidemann > on stacking layers: > > http://www.isi.edu/~johnh/WORK/index.html I've collected all relevant papers on stacking, which you can find on my FiST home page: http://www.cs.columbia.edu/~ezk/research/fist/ and also in the URL ftp://shekel.mcl.cs.columbia.edu/pub/ezk/stacking.tar.gz Erez. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Apr 9 22:39:47 2000 Delivered-To: freebsd-fs@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 7D85B37B742 for ; Sun, 9 Apr 2000 22:39:43 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id BAA11057 for ; Mon, 10 Apr 2000 01:39:42 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Mon, 10 Apr 2000 01:39:41 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-fs@freebsd.org Subject: file system extended attributes support Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As part of the supporting code base for a number of security-related projects on FreeBSD, I've hacked up extended attribute support for FreeBSD. This allows arbitrary named attributes to be associated with each inode, maintained by the kernel. In December, I committed APIs associated with this code to the FreeBSD repository, and now after a few months of testing and use, I'd like to commit the code itself to the repo. Doing so will facilitate the further development of a number of security-related projects, including the TrustedBSD MAC, ACL, and Capability support, as well as third party security code such as the NAI/TIS Labs FreeDTE code. This code is similar to the Quota code, in that it stores attributes in backing files in the file system (or in another file system), and may be enabled per-FFS partition. My feeling is that this approach allows maximum flexibility at this point in the life cycle of FreeBSD in terms of VFS maturity. As the support for stacked file systems matures, I'd be willing to reconsider the manner in which this is implemented. The current version of the code, diff'd from the main repo a few days ago on the 5.0-CURRENT (head) branch, is available for download at: http://www.trustedbsd.org/downloads/ It contains a great deal of #ifdef'd debugging code, but also contains some utilities that can be experimented with. I recommend reading the extattrctl man page first. The excessive debugging code will be stripped before committing, and once I'm confident that it works for more than just the four or five people who've used it thus far :-). Thanks, Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Apr 10 4: 7: 4 2000 Delivered-To: freebsd-fs@freebsd.org Received: from ewok.creative.net.au (fuzzy.aussie.com.au [203.30.44.82]) by hub.freebsd.org (Postfix) with SMTP id 6EB7337B569 for ; Mon, 10 Apr 2000 04:07:00 -0700 (PDT) (envelope-from freebsd@ewok.creative.net.au) Received: (qmail 18331 invoked by uid 1008); 10 Apr 2000 11:06:57 -0000 Date: Mon, 10 Apr 2000 19:06:57 +0800 From: Adrian Chadd To: John Estess Cc: freebsd-fs@freebsd.org Subject: Re: UNIONFS Message-ID: <20000410190656.B18146@ewok.creative.net.au> References: <38EF5E0D.1B06FDD5@wcnet.net> <38EF6FAD.44DF0965@wcnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <38EF6FAD.44DF0965@wcnet.net>; from John Estess on Sat, Apr 08, 2000 at 12:43:09PM -0500 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Apr 08, 2000, John Estess wrote: > hate to answer my own post, but... > > > like the inability to umount(no kidding - am I > > doing something wrong?). Also, a whiteout file was affected. Yes, I'll > > recheck that - that didn't make sense. > > Works correctly on both counts. (double) Whoops. Heh. I've been looking at this bug, and I'm not impressed. It looks like a VM/unionfs problem, however there are plenty of other unionfs weirdnesses (including one where if you pwd while running a script which happens to exist in the upper directory and not the lower one, it returns the upper dir pathname, breaking lots of configure type stuff. I don't know whether this is a bad thing or not, to be honest :-) which I'm going to be looking at over the next few weeks and submit some patches. Adrian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Apr 10 11:39:35 2000 Delivered-To: freebsd-fs@freebsd.org Received: from ewok.creative.net.au (fuzzy.aussie.com.au [203.30.44.82]) by hub.freebsd.org (Postfix) with SMTP id 18B5F37BCCF for ; Mon, 10 Apr 2000 11:39:25 -0700 (PDT) (envelope-from freebsd@ewok.creative.net.au) Received: (qmail 20709 invoked by uid 1008); 10 Apr 2000 18:39:20 -0000 Date: Tue, 11 Apr 2000 02:39:20 +0800 From: Adrian Chadd To: Robert Watson Cc: freebsd-fs@freebsd.org Subject: Re: file system extended attributes support Message-ID: <20000411023919.A20569@ewok.creative.net.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Robert Watson on Mon, Apr 10, 2000 at 01:39:41AM -0400 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Apr 10, 2000, Robert Watson wrote: > > As part of the supporting code base for a number of security-related > projects on FreeBSD, I've hacked up extended attribute support for > FreeBSD. This allows arbitrary named attributes to be associated with > each inode, maintained by the kernel. In December, I committed APIs > associated with this code to the FreeBSD repository, and now after a few > months of testing and use, I'd like to commit the code itself to the repo. > Doing so will facilitate the further development of a number of > security-related projects, including the TrustedBSD MAC, ACL, and > Capability support, as well as third party security code such as the > NAI/TIS Labs FreeDTE code. > > This code is similar to the Quota code, in that it stores attributes in > backing files in the file system (or in another file system), and may be > enabled per-FFS partition. My feeling is that this approach allows > maximum flexibility at this point in the life cycle of FreeBSD in terms of > VFS maturity. As the support for stacked file systems matures, I'd be > willing to reconsider the manner in which this is implemented. > > The current version of the code, diff'd from the main repo a few days ago > on the 5.0-CURRENT (head) branch, is available for download at: > > http://www.trustedbsd.org/downloads/ > > It contains a great deal of #ifdef'd debugging code, but also contains > some utilities that can be experimented with. I recommend reading the > extattrctl man page first. The excessive debugging code will be stripped > before committing, and once I'm confident that it works for more than just > the four or five people who've used it thus far :-). I've looked at this and although I haven't tried it, it looks nice. The last time I looked at it the debugging code needed a little sanity. I'll deal with you as I move forward on the VFS stacking layer stuff. Adrian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Apr 13 19:46: 3 2000 Delivered-To: freebsd-fs@freebsd.org Received: from daedalus.cs.brandeis.edu (daedalus.cs.brandeis.edu [129.64.3.179]) by hub.freebsd.org (Postfix) with ESMTP id 4561C37B539 for ; Thu, 13 Apr 2000 19:46:01 -0700 (PDT) (envelope-from meshko@daedalus.cs.brandeis.edu) Received: from localhost (meshko@localhost) by daedalus.cs.brandeis.edu (8.9.3/8.9.3) with ESMTP id WAA27933 for ; Thu, 13 Apr 2000 22:46:29 -0400 Date: Thu, 13 Apr 2000 22:46:28 -0400 (EDT) From: Mikhail Kruk To: freebsd-fs@freebsd.org Subject: userland nfs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, sorry if this is off-topic question but I really need some advice and thought that somebody on this list might help me out. I am looking for a topic for senior thesis and came up with an idea of a file sharing tool, something like nfs which would have the following properties: * run as a userland process without root privileges * allow different sharing modes (e.g. async, locks, cvs/coda-style with merging, may be something else) * support for ACLs * support for multiple daemons on the same host, i.e. if two users want to share their files at the same time their servers will cooperate Of course I am thinking of implementing it on FreeBSD (though as user process it should not depend on OS/kernel) I would really appreciate any feedback on that idea... is this complete bs? did someone do it already? is it worth trying? tia, mk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Apr 14 7:53:51 2000 Delivered-To: freebsd-fs@freebsd.org Received: from daedalus.cs.brandeis.edu (daedalus.cs.brandeis.edu [129.64.3.179]) by hub.freebsd.org (Postfix) with ESMTP id 1C9AC37B7A2 for ; Fri, 14 Apr 2000 07:53:49 -0700 (PDT) (envelope-from meshko@daedalus.cs.brandeis.edu) Received: from localhost (meshko@localhost) by daedalus.cs.brandeis.edu (8.9.3/8.9.3) with ESMTP id KAA30634; Fri, 14 Apr 2000 10:53:22 -0400 Date: Fri, 14 Apr 2000 10:53:22 -0400 (EDT) From: Mikhail Kruk To: Michael Chin-Yuan Wu Cc: freebsd-fs@freebsd.org Subject: Re: userland nfs In-Reply-To: <002001bfa60b$69d3c300$d60b1b18@austin.rr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 14 Apr 2000, Michael Chin-Yuan Wu wrote: > | I am looking for a topic for senior thesis and came up with an idea of a > | file sharing tool, something like nfs which would have the following > | properties: > | * run as a userland process without root privileges > | * allow different sharing modes (e.g. async, locks, cvs/coda-style with > | merging, may be something else) > > You do realize that there exists applications for each of the things > you want? All you have to do is integrate them. Well, I am aware of the ACLs implementation for various Unix file systems Not so sure about sharing files without running something like nfs. Can you point me at some examples? > | * support for ACLs > | * support for multiple daemons on the same host, i.e. if two users want to > | share their files at the same time their servers will cooperate > > * support for non-English languages may be... it would depend on the underlying system support for the localized characters in file names, right? > | Of course I am thinking of implementing it on FreeBSD (though as user > | process it should not depend on OS/kernel) > > Um... Coda? Samba? :) well, Coda is on the whole different level. It's a file system, not a high level sharing tool. And samba is just for compatability with MS protocols... So i guess what I am talking about is a bit different. No? thanks for response :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Apr 14 10:32:13 2000 Delivered-To: freebsd-fs@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 5BC0137BF20; Fri, 14 Apr 2000 10:32:06 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id NAA59477; Fri, 14 Apr 2000 13:32:02 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Fri, 14 Apr 2000 13:32:01 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-fs@freebsd.org Cc: freebsd-arch@freebsd.org Subject: going to commit (was: Re: file system extended attributes support) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I sent this out a few days ago, and have thus far received only postive comments. With this in mind, I'm going to go ahead and commit the FFS extended attribute support to 5.0-CURRENT this evening, modulo the following changes -- 1) clean up debugging output 2) possibly have the various baby extattr tools be a single binary that checks argv[0] Are there, at this point, any objections to my committing, or suggestions as to improvements that should be made? Just as a recap: enabling of extended attributes is toggled by the FFS_EXTATTR kernel option, and following that, it must be 1) started for each fs to be used, and 2) specific extended attributes must be explicitely enabled. Current this is done using the extattrctl utility, although I'm contemplating pushing some management info into /etc/fstab as with quotas, or having a startup script that auto-starts attributes in the /.attributes directory on each fs. Auto-starting will wait until I've seen more broad testing with it in the code base. Robert On Mon, 10 Apr 2000, Robert Watson wrote: > As part of the supporting code base for a number of security-related > projects on FreeBSD, I've hacked up extended attribute support for > FreeBSD. This allows arbitrary named attributes to be associated with > each inode, maintained by the kernel. In December, I committed APIs > associated with this code to the FreeBSD repository, and now after a few > months of testing and use, I'd like to commit the code itself to the repo. > Doing so will facilitate the further development of a number of > security-related projects, including the TrustedBSD MAC, ACL, and > Capability support, as well as third party security code such as the > NAI/TIS Labs FreeDTE code. > > This code is similar to the Quota code, in that it stores attributes in > backing files in the file system (or in another file system), and may be > enabled per-FFS partition. My feeling is that this approach allows > maximum flexibility at this point in the life cycle of FreeBSD in terms of > VFS maturity. As the support for stacked file systems matures, I'd be > willing to reconsider the manner in which this is implemented. > > The current version of the code, diff'd from the main repo a few days ago > on the 5.0-CURRENT (head) branch, is available for download at: > > http://www.trustedbsd.org/downloads/ > > It contains a great deal of #ifdef'd debugging code, but also contains > some utilities that can be experimented with. I recommend reading the > extattrctl man page first. The excessive debugging code will be stripped > before committing, and once I'm confident that it works for more than just > the four or five people who've used it thus far :-). > > Thanks, > > Robert N M Watson > > robert@fledge.watson.org http://www.watson.org/~robert/ > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > TIS Labs at Network Associates, Safeport Network Services > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-fs" in the body of the message > Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Apr 14 11:20:55 2000 Delivered-To: freebsd-fs@freebsd.org Received: from borderware.com (gateway.borderware.com [207.236.65.226]) by hub.freebsd.org (Postfix) with ESMTP id 1100437BF3E; Fri, 14 Apr 2000 11:20:43 -0700 (PDT) (envelope-from dchapes@borderware.com) Received: by gateway.borderware.com id <117140>; Fri, 14 Apr 2000 14:19:08 -0400 From: Dave Chapeskie Message-Id: <00Apr14.141908edt.117140@gateway.borderware.com> Date: Fri, 14 Apr 2000 14:20:37 -0400 To: freebsd-hackers@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: vnode_free_list corruption [patch] Reply-To: freebsd-fs@FreeBSD.ORG, dchapes@borderware.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=GvXjxJ+pjyke8COw X-Mailer: Mutt 0.93.2i Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Greetings. I've been seeing a rash of "free vnode isn't" panics lately. Some machines were panicing several times a day. Along with this we saw occasional "object inconsistent state: RPC: %d, RC: %d" messages. I was able to replicate the problem by running multiple (~8 on a pentium 200 system with 32 MB of RAM) copies of each of the attached simple shell scripts (with all output redirected to /dev/null). It would often panic within 10-20 minutes. I tracked the problem down to a race between getnewvnode() recycling a vnode and vhold(). I found that vhold() was calling vbusy() for a vnode with the VDOOMED flag set. This is bad since getnewvnode() removes the vnode from the free list before setting this flag so vbusy() is calling TAILQ_REMOVE for a vnode that is not on the free list. This can easily result in corruption of the free list pointers causing future getnewvnode() calls to find active vnodes that it thinks are on the free list. I added a panic in vbusy() if VDOOMED is set and this hit quite often during my tests. Typically the call chain looked something like: ffs_truncate ffs_indirtrunc getblk bgetvp vhold vbusy panic With ffs_truncate often being called due to rename(2) or unlink(2). I managed to solve the problem here by adding a VOP_ISLOCKED(vp) check to getnewvnode() and skipping such vnodes instead of trying to recycle them. From my searches of the mailing lists it appears I'm not the first one to think of this but apparently this isn't guaranteed to work for all files system types. I just know it works for the FFS problems I was seeing. At a minimum I'd highly recommend that someone commit a panic to vbusy() for vnodes with VDOOMED set since letting it continue if that flag is set can and does result in the corruption of the vnode_free_list. I'd also recommend the addition of the VOP_ISLOCKED() check to getnewvnode() even if it doesn't work for all file system types it will help in some (most?) cases. A patch for CURRENT is attached. -- Dave Chapeskie Senior Software Engineer Borderware Technologies Inc. --GvXjxJ+pjyke8COw Content-Type: application/x-sh Content-Disposition: attachment; filename="cp_mv_loop.sh" #!/bin/sh cd /var/log while true; do mkdir copy; cp * copy mkdir copy/2; mv copy/* copy/2 rm -rf copy done --GvXjxJ+pjyke8COw Content-Type: application/x-sh Content-Disposition: attachment; filename="find_loop.sh" #!/bin/sh FS="/tmp /var /usr" while true; do for f in $FS; do find -x $f -type f -print | xargs -n 4 head -1 done done --GvXjxJ+pjyke8COw Content-Type: application/x-sh Content-Disposition: attachment; filename="ps_loop.sh" #!/bin/sh while true; do ps -aux; ps -ajx done --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="vfs_subr.c.diff" diff -u -t -r1.253 vfs_subr.c --- kern/vfs_subr.c 2000/03/20 11:28:45 1.253 +++ kern/vfs_subr.c 2000/04/14 18:01:52 @@ -467,6 +467,8 @@ for (vp = TAILQ_FIRST(&vnode_tobefree_list); vp; vp = nvp) { nvp = TAILQ_NEXT(vp, v_freelist); + if (!simple_lock_try(&vp->v_interlock)) + continue; TAILQ_REMOVE(&vnode_tobefree_list, vp, v_freelist); if (vp->v_flag & VAGE) { TAILQ_INSERT_HEAD(&vnode_free_list, vp, v_freelist); @@ -478,6 +480,7 @@ if (vp->v_usecount) panic("tobe free vnode isn't"); freevnodes++; + simple_unlock(&tvp->v_interlock); } if (wantfreevnodes && freevnodes < wantfreevnodes) { @@ -507,6 +510,10 @@ /* Don't recycle if active in the namecache */ simple_unlock(&vp->v_interlock); continue; + } else if (VOP_ISLOCKED(vp)) + TAILQ_REMOVE(&vnode_free_list, vp, v_freelist); + TAILQ_INSERT_TAIL(&vnode_tmp_list, vp, v_freelist); + continue; } else { break; } @@ -2613,6 +2620,10 @@ int s; s = splbio(); + if (vp->v_flag & VDOOMED) { + vprint("vbusy", vp); + panic("vbusy on VDOOMED vnode"); + } simple_lock(&vnode_free_list_slock); if (vp->v_flag & VTBFREE) { TAILQ_REMOVE(&vnode_tobefree_list, vp, v_freelist); --GvXjxJ+pjyke8COw-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Apr 14 11:32: 8 2000 Delivered-To: freebsd-fs@freebsd.org Received: from ewok.creative.net.au (fuzzy.aussie.com.au [203.30.44.82]) by hub.freebsd.org (Postfix) with SMTP id 18FA137B5C2 for ; Fri, 14 Apr 2000 11:32:04 -0700 (PDT) (envelope-from freebsd@ewok.creative.net.au) Received: (qmail 47746 invoked by uid 1008); 14 Apr 2000 18:31:49 -0000 Date: Sat, 15 Apr 2000 02:31:49 +0800 From: Adrian Chadd To: freebsd-fs@FreeBSD.ORG, dchapes@borderware.com Cc: freebsd-hackers@freebsd.org Subject: Re: vnode_free_list corruption [patch] Message-ID: <20000415023148.F34852@ewok.creative.net.au> References: <00Apr14.141908edt.117140@gateway.borderware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <00Apr14.141908edt.117140@gateway.borderware.com>; from Dave Chapeskie on Fri, Apr 14, 2000 at 02:20:37PM -0400 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Apr 14, 2000, Dave Chapeskie wrote: > Greetings. > > I've been seeing a rash of "free vnode isn't" panics lately. Some > machines were panicing several times a day. Along with this we saw > occasional "object inconsistent state: RPC: %d, RC: %d" messages. Throw it into a PR, and I'll assign it to myself and take a squizz.. Adrian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Apr 14 11:35:31 2000 Delivered-To: freebsd-fs@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 90B7C37B686; Fri, 14 Apr 2000 11:35:26 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA71253; Fri, 14 Apr 2000 11:35:21 -0700 (PDT) (envelope-from dillon) Date: Fri, 14 Apr 2000 11:35:21 -0700 (PDT) From: Matthew Dillon Message-Id: <200004141835.LAA71253@apollo.backplane.com> To: Adrian Chadd Cc: freebsd-fs@FreeBSD.ORG, dchapes@borderware.com, freebsd-hackers@FreeBSD.ORG Subject: Re: vnode_free_list corruption [patch] References: <00Apr14.141908edt.117140@gateway.borderware.com> <20000415023148.F34852@ewok.creative.net.au> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :On Fri, Apr 14, 2000, Dave Chapeskie wrote: :> Greetings. :> :> I've been seeing a rash of "free vnode isn't" panics lately. Some :> machines were panicing several times a day. Along with this we saw :> occasional "object inconsistent state: RPC: %d, RC: %d" messages. : : :Throw it into a PR, and I'll assign it to myself and take a squizz.. : : :Adrian I'll take a look at it too. Either way we'll get something committed. Beware, though, even though there is obviously a bug (Dave obviously found the bug!), the vgone/vdone/VDEAD interaction is extremely complex so we have to be careful not to break other things while fixing this one. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message