From owner-freebsd-fs Sun Oct 25 01:15:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA20934 for freebsd-fs-outgoing; Sun, 25 Oct 1998 01:15:23 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from nutcracker.e.kth.se (nutcracker.e.kth.se [130.237.43.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA20929; Sun, 25 Oct 1998 01:15:16 -0800 (PST) (envelope-from lha@nutcracker.e.kth.se) Received: (from lha@localhost) by nutcracker.e.kth.se (8.8.8/8.8.8) id JAA05540; Sun, 25 Oct 1998 09:12:55 GMT (envelope-from lha) Date: Sun, 25 Oct 1998 09:12:55 GMT Message-Id: <199810250912.JAA05540@nutcracker.e.kth.se> From: Love To: freebsd-fs@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, kom-arla@stacken.kth.se Subject: deadfs in FreeBSD 3.0/current ? Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello kern/vfs_subr.c:vclean() does a vp->v_flag |= VXLOCK; and after that "calls" VOP_LOCK(). Now when the filesystem is deadfs (we use it in arla[1]), the call ends up in miscfs/deadfs/dead_vnops.c:dead_lock() that calls chkvnlock(). Now chkvnlock() sleeps when VXLOCK is set. Who will wake us up ? Love, arla-drinker [1] arla, a free afs-clone To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Oct 25 01:53:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA23951 for freebsd-fs-outgoing; Sun, 25 Oct 1998 01:53:53 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from sv01.cet.co.jp (sv01.cet.co.jp [210.171.56.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA23933; Sun, 25 Oct 1998 01:53:51 -0800 (PST) (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by sv01.cet.co.jp (8.8.8/8.8.8) with SMTP id JAA01021; Sun, 25 Oct 1998 09:53:50 GMT (envelope-from michaelh@cet.co.jp) Date: Sun, 25 Oct 1998 18:53:50 +0900 (JST) From: Michael Hancock To: Love cc: freebsd-fs@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, kom-arla@stacken.kth.se Subject: Re: deadfs in FreeBSD 3.0/current ? In-Reply-To: <199810250912.JAA05540@nutcracker.e.kth.se> 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 The wakeup at the bottom of vclean()? That code also clears VXLOCK. Regards, Mike On Sun, 25 Oct 1998, Love wrote: > > Hello > > kern/vfs_subr.c:vclean() does a vp->v_flag |= VXLOCK; and after that > "calls" VOP_LOCK(). > > Now when the filesystem is deadfs (we use it in arla[1]), the call > ends up in miscfs/deadfs/dead_vnops.c:dead_lock() that calls > chkvnlock(). Now chkvnlock() sleeps when VXLOCK is set. > > Who will wake us up ? > > Love, > arla-drinker > > [1] arla, a free afs-clone > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-fs" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Oct 25 03:06:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA28997 for freebsd-fs-outgoing; Sun, 25 Oct 1998 03:06:26 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from elixir.e.kth.se (elixir.e.kth.se [130.237.48.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA28978; Sun, 25 Oct 1998 03:06:21 -0800 (PST) (envelope-from lha@s3.kth.se) Received: from zinfandel.e.kth.se (1073744992@zinfandel.e.kth.se [130.237.48.172]) by elixir.e.kth.se (8.8.7/8.8.7) with ESMTP id MAA19263; Sun, 25 Oct 1998 12:05:45 +0100 (MET) Received: (lha@localhost) by zinfandel.e.kth.se (8.8.7/8.6.6) id MAA03108; Sun, 25 Oct 1998 12:05:44 +0100 (MET) To: Michael Hancock Cc: freebsd-fs@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, kom-arla@stacken.kth.se Subject: Re: deadfs in FreeBSD 3.0/current ? References: From: Love Date: 25 Oct 1998 12:05:44 +0100 In-Reply-To: Michael Hancock's message of Sun, 25 Oct 1998 18:53:50 +0900 (JST) Message-ID: Lines: 21 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Michael Hancock writes: > On Sun, 25 Oct 1998, Love wrote: > > > kern/vfs_subr.c:vclean() does a vp->v_flag |= VXLOCK; and after that > > "calls" VOP_LOCK(). > > > > Now when the filesystem is deadfs (we use it in arla[1]), the call > > ends up in miscfs/deadfs/dead_vnops.c:dead_lock() that calls > > chkvnlock(). Now chkvnlock() sleeps when VXLOCK is set. > > > > Who will wake us up ? > > > > The wakeup at the bottom of vclean()? That code also clears VXLOCK. But that is done *after* the tsleep, and therefor that code will *never* be reached. Kind of hard to wake yourself up. It will hang in miscfs/deadfs/dead_vnops.c(1.24):240 forever. Love To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Oct 25 03:49:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA05249 for freebsd-fs-outgoing; Sun, 25 Oct 1998 03:49:44 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from sv01.cet.co.jp (sv01.cet.co.jp [210.171.56.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA05189; Sun, 25 Oct 1998 03:49:36 -0800 (PST) (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by sv01.cet.co.jp (8.8.8/8.8.8) with SMTP id LAA01280; Sun, 25 Oct 1998 11:49:38 GMT (envelope-from michaelh@cet.co.jp) Date: Sun, 25 Oct 1998 20:49:38 +0900 (JST) From: Michael Hancock Reply-To: Michael Hancock To: Love cc: freebsd-fs@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, kom-arla@stacken.kth.se Subject: Re: deadfs in FreeBSD 3.0/current ? 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 On 25 Oct 1998, Love wrote: > > > kern/vfs_subr.c:vclean() does a vp->v_flag |= VXLOCK; and after that > > > "calls" VOP_LOCK(). > > > > > > Now when the filesystem is deadfs (we use it in arla[1]), the call > > > ends up in miscfs/deadfs/dead_vnops.c:dead_lock() that calls > > > chkvnlock(). Now chkvnlock() sleeps when VXLOCK is set. > > > > > > Who will wake us up ? > > > > The wakeup at the bottom of vclean()? That code also clears VXLOCK. > > But that is done *after* the tsleep, and therefor that code will *never* be > reached. Kind of hard to wake yourself up. It will hang in > miscfs/deadfs/dead_vnops.c(1.24):240 forever. Umm... Why are you using deadfs in arla? I think you're breaking an invariant if vclean is trying to clean out something that's already dead. Kinda like a double free. Regards, Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Oct 25 04:13:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA09808 for freebsd-fs-outgoing; Sun, 25 Oct 1998 04:13:44 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from sv01.cet.co.jp (sv01.cet.co.jp [210.171.56.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA09803 for ; Sun, 25 Oct 1998 04:13:43 -0800 (PST) (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by sv01.cet.co.jp (8.8.8/8.8.8) with SMTP id MAA01339; Sun, 25 Oct 1998 12:13:51 GMT (envelope-from michaelh@cet.co.jp) Date: Sun, 25 Oct 1998 21:13:51 +0900 (JST) From: Michael Hancock To: Love cc: freebsd-fs@FreeBSD.ORG, kom-arla@stacken.kth.se Subject: Re: deadfs in FreeBSD 3.0/current ? 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 On Sun, 25 Oct 1998, Michael Hancock wrote: > On 25 Oct 1998, Love wrote: > > > > > kern/vfs_subr.c:vclean() does a vp->v_flag |= VXLOCK; and after that > > > > "calls" VOP_LOCK(). > > > > > > > > Now when the filesystem is deadfs (we use it in arla[1]), the call > > > > ends up in miscfs/deadfs/dead_vnops.c:dead_lock() that calls > > > > chkvnlock(). Now chkvnlock() sleeps when VXLOCK is set. > > > > > > > > Who will wake us up ? > > > > > > The wakeup at the bottom of vclean()? That code also clears VXLOCK. > > > > But that is done *after* the tsleep, and therefor that code will *never* be > > reached. Kind of hard to wake yourself up. It will hang in > > miscfs/deadfs/dead_vnops.c(1.24):240 forever. > > Umm... Why are you using deadfs in arla? I think you're breaking an > invariant if vclean is trying to clean out something that's already dead. > Kinda like a double free. Sorry, let me guess. You're trying to cache vnodes but the kernel wants to control the lifetime of vnodes. With the global vnode management policy and how deadfs works this is tricky. You might want to look at how the Coda people solved this, I don't have a clue. Regards, Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Oct 25 06:18:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA16017 for freebsd-fs-outgoing; Sun, 25 Oct 1998 06:18:30 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from elixir.e.kth.se (elixir.e.kth.se [130.237.48.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA16001; Sun, 25 Oct 1998 06:18:25 -0800 (PST) (envelope-from lha@s3.kth.se) Received: from zinfandel.e.kth.se (1073744992@zinfandel.e.kth.se [130.237.48.172]) by elixir.e.kth.se (8.8.7/8.8.7) with ESMTP id PAA23255; Sun, 25 Oct 1998 15:17:50 +0100 (MET) Received: (lha@localhost) by zinfandel.e.kth.se (8.8.7/8.6.6) id PAA22897; Sun, 25 Oct 1998 15:17:50 +0100 (MET) To: Michael Hancock Cc: freebsd-fs@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, kom-arla@stacken.kth.se Subject: Re: deadfs in FreeBSD 3.0/current ? References: From: Love Date: 25 Oct 1998 15:17:50 +0100 In-Reply-To: Michael Hancock's message of Sun, 25 Oct 1998 20:49:38 +0900 (JST) Message-ID: Lines: 38 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Michael Hancock writes: > On 25 Oct 1998, Love wrote: > > > But that is done *after* the tsleep, and therefor that code will *never* be > > reached. Kind of hard to wake yourself up. It will hang in > > miscfs/deadfs/dead_vnops.c(1.24):240 forever. > > Umm... Why are you using deadfs in arla? I think you're breaking an > invariant if vclean is trying to clean out something that's already dead. > Kinda like a double free. > >Sorry, let me guess. You're trying to cache vnodes but the kernel wants >to control the lifetime of vnodes. With the global vnode management >policy and how deadfs works this is tricky. You might want to look at how >the Coda people solved this, I don't have a clue. Arla is like coda (http://www.coda.cs.cmu.edu/) and has a userland daemon that keeps track of all things, the kernel module does caching to keep the speed up. But then the userland-daemon is dead you have to return something in the kernel-module so we do: return getnewvnode(VT_NON, mp, dead_vnodeop_p, vpp);} Because we don't want to do magic with xfs_vnodeops_p when there is no userland daemon, they do that with coda. So you have a deadvnodeops that isn't really vnodeops or what (just used the small timeframe from when a vnode is vclean()ed to its assigned to a new filesystem by checkalias(), vflush(), or vgonel() ?) Should we bake our own dead_vnodeops_p that is really dead vnodes ? Love To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Oct 25 06:52:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA17719 for freebsd-fs-outgoing; Sun, 25 Oct 1998 06:52:07 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from sundance.stacken.kth.se (sundance.stacken.kth.se [130.237.234.41]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA17703; Sun, 25 Oct 1998 06:52:02 -0800 (PST) (envelope-from art@stacken.kth.se) Received: from pizza.stacken.kth.se (pizza.stacken.kth.se [130.237.234.73]) by sundance.stacken.kth.se (8.8.8/8.8.8) with ESMTP id PAA12316; Sun, 25 Oct 1998 15:51:26 +0100 (MET) Received: (from art@localhost) by pizza.stacken.kth.se (8.8.7/8.8.7) id PAA09327; Sun, 25 Oct 1998 15:51:53 +0100 (MET) To: Love Cc: freebsd-fs@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, kom-arla@stacken.kth.se Subject: Re: deadfs in FreeBSD 3.0/current ? References: <199810250912.JAA05540@nutcracker.e.kth.se> From: Artur Grabowski Date: 25 Oct 1998 15:51:52 +0100 In-Reply-To: Love's message of "Sun, 25 Oct 1998 09:12:55 GMT" Message-ID: Lines: 16 X-Mailer: Gnus v5.6.44/Emacs 19.34 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Love writes: > Hello > > kern/vfs_subr.c:vclean() does a vp->v_flag |= VXLOCK; and after that > "calls" VOP_LOCK(). > > Now when the filesystem is deadfs (we use it in arla[1]), the call > ends up in miscfs/deadfs/dead_vnops.c:dead_lock() that calls > chkvnlock(). Now chkvnlock() sleeps when VXLOCK is set. As a horrible workaround in OpenBSD I noted that LK_DRAIN is set in the VOP_LOCK call in vclean. (The code is not checked in, our tree is locked). And when the LK_DRAIN is set I don't do the chkvnlock(). //art To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Oct 25 06:57:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA18043 for freebsd-fs-outgoing; Sun, 25 Oct 1998 06:57:04 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from sv01.cet.co.jp (sv01.cet.co.jp [210.171.56.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA18036 for ; Sun, 25 Oct 1998 06:57:02 -0800 (PST) (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by sv01.cet.co.jp (8.8.8/8.8.8) with SMTP id OAA01736; Sun, 25 Oct 1998 14:57:09 GMT (envelope-from michaelh@cet.co.jp) Date: Sun, 25 Oct 1998 23:57:09 +0900 (JST) From: Michael Hancock To: Love cc: freebsd-fs@FreeBSD.ORG, kom-arla@stacken.kth.se Subject: Re: deadfs in FreeBSD 3.0/current ? 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 [bugs trimmed] On 25 Oct 1998, Love wrote: > > Umm... Why are you using deadfs in arla? I think you're breaking an > > invariant if vclean is trying to clean out something that's already dead. > > Kinda like a double free. > > > >Sorry, let me guess. You're trying to cache vnodes but the kernel wants > >to control the lifetime of vnodes. With the global vnode management > >policy and how deadfs works this is tricky. You might want to look at how > >the Coda people solved this, I don't have a clue. > > Arla is like coda (http://www.coda.cs.cmu.edu/) and has a userland daemon > that keeps track of all things, the kernel module does caching to keep the > speed up. But then the userland-daemon is dead you have to return something > in the kernel-module so we do: > > return getnewvnode(VT_NON, mp, dead_vnodeop_p, vpp);} > > Because we don't want to do magic with xfs_vnodeops_p when there is no > userland daemon, they do that with coda. > > So you have a deadvnodeops that isn't really vnodeops or what (just used the > small timeframe from when a vnode is vclean()ed to its assigned to a new > filesystem by checkalias(), vflush(), or vgonel() ?) > > Should we bake our own dead_vnodeops_p that is really dead vnodes ? I don't know. Our vnode constructors/destructors are handled by central code for all file systems. It's pretty intertwined in the VFS and VOP layers. Having this global policy provided good memory utilization, but it isn't very flexible. I was looking at this a while ago and was thinking of putting the vnode management into the VFS layer so that a file system could have the option to manage its own vnodes or just wrap the default stuff: getnewvnode, vput, vrele, vclean, vgone, VOP_INACTIVE, etc. We already have a VFS_VGET which wraps getnewvnode, but this is for a specific case where you need to get a vnode given an inode. You would need to make something like VFS_VALLOC, and maybe VFS_(VRELE|VPUT). This way you could make it so that you had your own pool of vnodes that never get vclean'ed and retyped as another file system vnode. I started doing VFS_VRELE, but you need to bring in the VFS infrastructure, like mount.h, all over the VOP code for each file system implementation. After working with a little bit I realized that it needed to be thought out more and then I got to busy to follow-up on it. You might be able to take a different approach by holding ref counts and doing some tricks with VOP_INACTIVE on the destructor side. We'd be hosed if active vnodes were revoked, but I'm not sure if this really happens anymore. I wish I had the time to go back and do the analysis and design. Anyway, that's one idea. Maybe the Coda magic isn't so bad. Regards, Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Oct 25 07:21:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA19913 for freebsd-fs-outgoing; Sun, 25 Oct 1998 07:21:47 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from elixir.e.kth.se (elixir.e.kth.se [130.237.48.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA19814 for ; Sun, 25 Oct 1998 07:21:44 -0800 (PST) (envelope-from lha@s3.kth.se) Received: from zinfandel.e.kth.se (1073744992@zinfandel.e.kth.se [130.237.48.172]) by elixir.e.kth.se (8.8.7/8.8.7) with ESMTP id QAA11273; Sun, 25 Oct 1998 16:21:09 +0100 (MET) Received: (lha@localhost) by zinfandel.e.kth.se (8.8.7/8.6.6) id QAA26745; Sun, 25 Oct 1998 16:21:09 +0100 (MET) To: Michael Hancock Cc: freebsd-fs@FreeBSD.ORG, kom-arla@stacken.kth.se Subject: Re: deadfs in FreeBSD 3.0/current ? References: From: Love Date: 25 Oct 1998 16:21:08 +0100 In-Reply-To: Michael Hancock's message of Sun, 25 Oct 1998 23:57:09 +0900 (JST) Message-ID: Lines: 21 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Michael Hancock writes: > > Should we bake our own dead_vnodeops_p that is really dead vnodes ? > > I don't know. I think we dont talk about the same thing. All I want is a vnodeops that dead, they shouldn't do anything. We thought that dead_vnodeops_p was written just for this, guess we was wrong. We dont want to do any special vnode management. I consider it a bug if on of the vnodeops make the vfs sleep forever. > Anyway, that's one idea. Maybe the Coda magic isn't so bad. I don't think to. Guess that we will build our own deadvnodeops. Love To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Oct 25 07:25:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA20254 for freebsd-fs-outgoing; Sun, 25 Oct 1998 07:25:43 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from bg.sics.se (bg.sics.se [193.10.66.124]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA20248; Sun, 25 Oct 1998 07:25:40 -0800 (PST) (envelope-from bg@bg.sics.se) Received: (from bg@localhost) by bg.sics.se (8.8.5/8.8.5) id QAA29863; Sun, 25 Oct 1998 16:27:25 +0100 (CET) To: Love Cc: Michael Hancock , freebsd-fs@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, kom-arla@stacken.kth.se Subject: Re: deadfs in FreeBSD 3.0/current ? References: From: Bjoern Groenvall Date: 25 Oct 1998 16:27:25 +0100 In-Reply-To: Love's message of 25 Oct 1998 15:17:50 +0100 Message-ID: Lines: 50 X-Mailer: Red Gnus v0.52/Emacs 19.34 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Love writes: > Michael Hancock writes: > > > On 25 Oct 1998, Love wrote: > > > > > But that is done *after* the tsleep, and therefor that code will *never* be > > > reached. Kind of hard to wake yourself up. It will hang in > > > miscfs/deadfs/dead_vnops.c(1.24):240 forever. > > > > Umm... Why are you using deadfs in arla? I think you're breaking an > > invariant if vclean is trying to clean out something that's already dead. > > Kinda like a double free. > > > >Sorry, let me guess. You're trying to cache vnodes but the kernel wants > >to control the lifetime of vnodes. With the global vnode management > >policy and how deadfs works this is tricky. You might want to look at how > >the Coda people solved this, I don't have a clue. > > Arla is like coda (http://www.coda.cs.cmu.edu/) and has a userland daemon > that keeps track of all things, the kernel module does caching to keep the > speed up. But then the userland-daemon is dead you have to return something > in the kernel-module so we do: > > return getnewvnode(VT_NON, mp, dead_vnodeop_p, vpp);} > > Because we don't want to do magic with xfs_vnodeops_p when there is no > userland daemon, they do that with coda. > > So you have a deadvnodeops that isn't really vnodeops or what (just used the > small timeframe from when a vnode is vclean()ed to its assigned to a new > filesystem by checkalias(), vflush(), or vgonel() ?) > > Should we bake our own dead_vnodeops_p that is really dead vnodes ? In the evil old days when I wrote xfs; dead vnodes was only used to be able to unmount xfs when there was no user space daemon running. Is it still required to have a root vnode to be able to unmount? If not, you no longer need that hack, it's enough to have xfs_root fail. Cheers, Björn -- _ _ ,_______________. Bjorn Gronvall (Björn Grönvall) /_______________/| Swedish Institute of Computer Science | || PO Box 1263, S-164 29 Kista, Sweden | Schroedingers || Email: bg@sics.se, Phone +46 -8 633 15 25 | Cat |/ Cellular +46 -70 768 06 35, Fax +46 -8 751 72 30 `---------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Oct 25 07:33:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA20984 for freebsd-fs-outgoing; Sun, 25 Oct 1998 07:33:12 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from elixir.e.kth.se (elixir.e.kth.se [130.237.48.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA20976 for ; Sun, 25 Oct 1998 07:33:09 -0800 (PST) (envelope-from lha@s3.kth.se) Received: from zinfandel.e.kth.se (1073744992@zinfandel.e.kth.se [130.237.48.172]) by elixir.e.kth.se (8.8.7/8.8.7) with ESMTP id QAA23770; Sun, 25 Oct 1998 16:32:28 +0100 (MET) Received: (lha@localhost) by zinfandel.e.kth.se (8.8.7/8.6.6) id QAA25420; Sun, 25 Oct 1998 16:32:28 +0100 (MET) To: Bjoern Groenvall Cc: Michael Hancock , freebsd-fs@FreeBSD.ORG, kom-arla@stacken.kth.se Subject: Re: deadfs in FreeBSD 3.0/current ? References: From: Love Date: 25 Oct 1998 16:32:28 +0100 In-Reply-To: Bjoern Groenvall's message of 25 Oct 1998 16:27:25 +0100 Message-ID: Lines: 17 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Bjoern Groenvall writes: > Love writes: > > > Should we bake our own dead_vnodeops_p that is really dead vnodes ? > > In the evil old days when I wrote xfs; dead vnodes was only used to be > able to unmount xfs when there was no user space daemon running. Is it > still required to have a root vnode to be able to unmount? If not, you > no longer need that hack, it's enough to have xfs_root fail. unmount() still does a lookup on the name and expects there to be no errors and the vnodes it gets back to be a VROOT. So dead vnodes are still needed. Love To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Oct 25 07:40:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA21798 for freebsd-fs-outgoing; Sun, 25 Oct 1998 07:40:33 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from bg.sics.se (bg.sics.se [193.10.66.124]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA21793 for ; Sun, 25 Oct 1998 07:40:30 -0800 (PST) (envelope-from bg@bg.sics.se) Received: (from bg@localhost) by bg.sics.se (8.8.5/8.8.5) id QAA29902; Sun, 25 Oct 1998 16:42:17 +0100 (CET) To: Love Cc: Bjoern Groenvall , Michael Hancock , freebsd-fs@FreeBSD.ORG, kom-arla@stacken.kth.se Subject: Re: deadfs in FreeBSD 3.0/current ? References: From: Bjoern Groenvall Date: 25 Oct 1998 16:42:17 +0100 In-Reply-To: Love's message of 25 Oct 1998 16:32:28 +0100 Message-ID: Lines: 30 X-Mailer: Red Gnus v0.52/Emacs 19.34 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Love writes: > Bjoern Groenvall writes: > > > Love writes: > > > > > Should we bake our own dead_vnodeops_p that is really dead vnodes ? > > > > In the evil old days when I wrote xfs; dead vnodes was only used to be > > able to unmount xfs when there was no user space daemon running. Is it > > still required to have a root vnode to be able to unmount? If not, you > > no longer need that hack, it's enough to have xfs_root fail. > > unmount() still does a lookup on the name and expects there to be no errors > and the vnodes it gets back to be a VROOT. > > So dead vnodes are still needed. In that case you better use a custom dead root vnode rather than the BSD dead vnode. /Björn -- _ _ ,_______________. Bjorn Gronvall (Björn Grönvall) /_______________/| Swedish Institute of Computer Science | || PO Box 1263, S-164 29 Kista, Sweden | Schroedingers || Email: bg@sics.se, Phone +46 -8 633 15 25 | Cat |/ Cellular +46 -70 768 06 35, Fax +46 -8 751 72 30 `---------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Oct 25 19:12:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA16795 for freebsd-fs-outgoing; Sun, 25 Oct 1998 19:12:33 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from sv01.cet.co.jp (sv01.cet.co.jp [210.171.56.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA16789 for ; Sun, 25 Oct 1998 19:12:31 -0800 (PST) (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by sv01.cet.co.jp (8.8.8/8.8.8) with SMTP id DAA01777; Mon, 26 Oct 1998 03:12:40 GMT (envelope-from michaelh@cet.co.jp) Date: Mon, 26 Oct 1998 12:12:40 +0900 (JST) From: Michael Hancock To: Love cc: freebsd-fs@FreeBSD.ORG, kom-arla@stacken.kth.se Subject: Re: deadfs in FreeBSD 3.0/current ? 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 On 25 Oct 1998, Love wrote: > > > Should we bake our own dead_vnodeops_p that is really dead vnodes ? > > > > I don't know. > > I think we dont talk about the same thing. > > All I want is a vnodeops that dead, they shouldn't do anything. We thought > that dead_vnodeops_p was written just for this, guess we was wrong. Yes, dead_vnodeops are for when you want the vfs to reclaim the vnode. If you want noop_vnodeops then you need to roll your own. > We dont want to do any special vnode management. > I consider it a bug if on of the vnodeops make the vfs sleep forever. If the vfs were a userland interface then yes, but since this is the kernel you need to know how to use it without stopping the kernel. If the kernel were object-oriented then dead_vnodeops would be hidden from you. For a userland interface to deadfs man revoke(2). Regards, Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Oct 25 21:59:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA03765 for freebsd-fs-outgoing; Sun, 25 Oct 1998 21:59:42 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from chickenbean.ais-gwd.com (chickenbean.com [205.160.97.50]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA03574; Sun, 25 Oct 1998 21:57:41 -0800 (PST) (envelope-from charlespeters@chickenbean.com) Received: from ci1000971-d.sptnbrg1.sc.home.com (ci1000971-d.sptnbrg1.sc.home.com [24.4.115.200]) by chickenbean.ais-gwd.com (8.8.8/8.8.8) with SMTP id BAA02260; Mon, 26 Oct 1998 01:09:12 -0500 (EST) (envelope-from charlespeters@chickenbean.com) Reply-To: From: "Charles A. Peters" To: , , , , , , , , , , , , , , , , Date: Mon, 26 Oct 1998 00:51:11 -0500 Message-ID: <000001be00a5$5e2d8d40$c8730418@ci1000971-d.sptnbrg1.sc.home.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org subscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Oct 26 01:32:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA22017 for freebsd-fs-outgoing; Mon, 26 Oct 1998 01:32:15 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA21992; Mon, 26 Oct 1998 01:32:04 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id KAA23645; Mon, 26 Oct 1998 10:31:20 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (VMailer, from userid 101) id E94E51508; Mon, 26 Oct 1998 09:35:11 +0100 (CET) Date: Mon, 26 Oct 1998 09:35:11 +0100 From: Ollivier Robert To: freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching Message-ID: <19981026093511.A14275@keltia.freenix.fr> Mail-Followup-To: freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG References: <199810230013.RAA19305@salsa.gv.tsc.tdk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.4i In-Reply-To: <199810230013.RAA19305@salsa.gv.tsc.tdk.com>; from Don Lewis on Thu, Oct 22, 1998 at 05:13:09PM -0700 X-Operating-System: FreeBSD 3.0-BETA/ELF ctm#4731 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Don Lewis: > That's certainly not my experience. Once the initiate_write_filepage > and newdirrem panics were fixed, my system has been completely stable. I agree. All my three systems are more stable now and the two using the ahc driver are faster under CAM. I've not see that much difference for the ncr driver. > I think you are thinking of NFS write caching. An NFS server isn't > supposed to tell the NFS client that the write has completed until No, I really talking about the WCE bit. SAM is very clear about this kernel value for HP-UX. There are two configurable variables, one is "async" mode (apparently you either have it for all I/O or not at all) and write caching (WCE). -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-BETA #4: Thu Oct 15 01:36:57 CEST 1998 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Oct 26 11:25:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA11304 for freebsd-fs-outgoing; Mon, 26 Oct 1998 11:25:59 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA11297; Mon, 26 Oct 1998 11:25:57 -0800 (PST) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id MAA02283; Mon, 26 Oct 1998 12:25:00 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp01.primenet.com, id smtpd002094; Mon Oct 26 12:24:44 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id MAA15542; Mon, 26 Oct 1998 12:24:38 -0700 (MST) From: Terry Lambert Message-Id: <199810261924.MAA15542@usr04.primenet.com> Subject: Re: deadfs in FreeBSD 3.0/current ? To: art@stacken.kth.se (Artur Grabowski) Date: Mon, 26 Oct 1998 19:24:37 +0000 (GMT) Cc: lha@s3.kth.se, freebsd-fs@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, kom-arla@stacken.kth.se In-Reply-To: from "Artur Grabowski" at Oct 25, 98 03:51:52 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > kern/vfs_subr.c:vclean() does a vp->v_flag |= VXLOCK; and after that > > "calls" VOP_LOCK(). > > > > Now when the filesystem is deadfs (we use it in arla[1]), the call > > ends up in miscfs/deadfs/dead_vnops.c:dead_lock() that calls > > chkvnlock(). Now chkvnlock() sleeps when VXLOCK is set. > > As a horrible workaround in OpenBSD I noted that LK_DRAIN is set in the > VOP_LOCK call in vclean. (The code is not checked in, our tree is locked). > And when the LK_DRAIN is set I don't do the chkvnlock(). Oh, look. People have started trying to do real work in the VFS code, and the first thing that rears its ugly head is a stacking layer issue that I identified about three years ago. As a workaround for the brain-damage in this area, look at the handling of vnodes of type VT_TFS, since TFS handles it's own vnode pool by severability rather than by correction of the interface bogosity. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Oct 26 11:35:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA12497 for freebsd-fs-outgoing; Mon, 26 Oct 1998 11:35:29 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA12490 for ; Mon, 26 Oct 1998 11:35:27 -0800 (PST) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id MAA03470; Mon, 26 Oct 1998 12:34:27 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp03.primenet.com, id smtpd003423; Mon Oct 26 12:34:22 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id MAA16077; Mon, 26 Oct 1998 12:34:19 -0700 (MST) From: Terry Lambert Message-Id: <199810261934.MAA16077@usr04.primenet.com> Subject: Re: deadfs in FreeBSD 3.0/current ? To: lha@e.kth.se (Love) Date: Mon, 26 Oct 1998 19:34:19 +0000 (GMT) Cc: michaelh@cet.co.jp, freebsd-fs@FreeBSD.ORG, kom-arla@stacken.kth.se In-Reply-To: from "Love" at Oct 25, 98 04:21:08 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > Should we bake our own dead_vnodeops_p that is really dead vnodes ? > > > > I don't know. > > I think we dont talk about the same thing. > > All I want is a vnodeops that dead, they shouldn't do anything. We thought > that dead_vnodeops_p was written just for this, guess we was wrong. Basically, this is a revocation operation, wherein it is not possible to unwind state because the revoking entity does not own its own vnode management. > We dont want to do any special vnode management. The problem is that you are attempting the revocation at a layer that is incorrect, given the implementation of a revoked object as an instance of the object relocated to another FS type. Really, with the existance of "deadfs" instead of a "VINALID" flag inspection by upper level code, there's no way to avoid this. The one way might be to lock the vnode and bounce it up to a higher layer for invalidation/discard. > I consider it a bug if on of the vnodeops make the vfs sleep forever. It's a bug; it's just not where you think it is. > > Anyway, that's one idea. Maybe the Coda magic isn't so bad. > > I don't think to. Guess that we will build our own deadvnodeops. I would actually avoid this, if possible. It just complicates things more. Really, I'd say you should design as if deadfs did not exist, and bounce the operation to a higher level. To do the FS specific code that you must be doing in the invalidation case, you need to implement an ioctl or fcntl covert path so that the upper level can notify you to do the cleanup. If the vnode is locked before return (all vnodes *should* be locked at all times below the vnode operations call boundary, but aren't) then there is no danger of a race between an unlock and the ioctl/fcntl covert channel, and another process that is attempting to use the cached object (the cache in this case is any struct file reference to the now invalid vnode). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Oct 26 18:33:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA26541 for freebsd-fs-outgoing; Mon, 26 Oct 1998 18:33:27 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from students.itb.ac.id (students.ITB.ac.id [167.205.22.114]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA26511 for ; Mon, 26 Oct 1998 18:33:18 -0800 (PST) (envelope-from otok@students.itb.ac.id) Received: from localhost (otok@localhost) by students.itb.ac.id (8.8.8/8.8.8) with SMTP id JAA28635; Tue, 27 Oct 1998 09:27:28 GMT (envelope-from otok@students.itb.ac.id) Date: Tue, 27 Oct 1998 09:27:27 +0000 (GMT) From: Otok Berliawan To: Terry Lambert cc: Love , michaelh@cet.co.jp, freebsd-fs@FreeBSD.ORG, kom-arla@stacken.kth.se Subject: Re: deadfs in FreeBSD 3.0/current ? In-Reply-To: <199810261934.MAA16077@usr04.primenet.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 I'm the new comer in FreeBSD enviroment,I have been confusing with this topic, can u explain me, what for the deadfs file???? thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Oct 26 20:40:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA08378 for freebsd-fs-outgoing; Mon, 26 Oct 1998 20:40:55 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from sv01.cet.co.jp (sv01.cet.co.jp [210.171.56.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA08373 for ; Mon, 26 Oct 1998 20:40:53 -0800 (PST) (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by sv01.cet.co.jp (8.8.8/8.8.8) with SMTP id EAA02853; Tue, 27 Oct 1998 04:40:34 GMT (envelope-from michaelh@cet.co.jp) Date: Tue, 27 Oct 1998 13:40:34 +0900 (JST) From: Michael Hancock To: Otok Berliawan cc: Terry Lambert , Love , freebsd-fs@FreeBSD.ORG, kom-arla@stacken.kth.se Subject: Re: deadfs in FreeBSD 3.0/current ? 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 Here's a reference, "The Design and Implementation of the 4.4BSD Operating System" by Marshall Kirk McKusick et al. Publisher: Addison Wesley. On Tue, 27 Oct 1998, Otok Berliawan wrote: > I'm the new comer in FreeBSD enviroment,I have been confusing with this > topic, can u explain me, what for the deadfs file???? > > thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Oct 27 14:17:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA00890 for freebsd-fs-outgoing; Tue, 27 Oct 1998 14:17:25 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA00879 for ; Tue, 27 Oct 1998 14:17:16 -0800 (PST) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id PAA15710; Tue, 27 Oct 1998 15:16:14 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp03.primenet.com, id smtpd015635; Tue Oct 27 15:16:08 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id PAA08872; Tue, 27 Oct 1998 15:15:53 -0700 (MST) From: Terry Lambert Message-Id: <199810272215.PAA08872@usr04.primenet.com> Subject: Re: deadfs in FreeBSD 3.0/current ? To: otok@students.itb.ac.id (Otok Berliawan) Date: Tue, 27 Oct 1998 22:15:53 +0000 (GMT) Cc: tlambert@primenet.com, lha@e.kth.se, michaelh@cet.co.jp, freebsd-fs@FreeBSD.ORG, kom-arla@stacken.kth.se In-Reply-To: from "Otok Berliawan" at Oct 27, 98 09:27:27 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I'm the new comer in FreeBSD enviroment,I have been confusing with this > topic, can u explain me, what for the deadfs file???? The "deadfs" VFS layer file system implementation is a file system that can be referenced by revoked vnodes without each FS needing to do revoked node management. It's a rather unsatisfying kludge to get around the fact that some file systems would like to manage their own vnode pool, but the vnode pool has been declared, by fiat, to be a system wide resource. Here are the gory details... The VFS implementation abstracts two interfaces: VFSOPS Operations on VFS objects, which are the exposed interfaces to instances of actual file systems VNOPS Operations on vnode objects, which are the exposed interfaces to instances of acutal files on a single file system instance It's important to undestand what a "file" is in order to understand the architecture, and thus the need for a deadfs. For right now, we're going to ignore the mount, unmount, and other per-fs operations, so we can concentrate on the VNOPS and totally ignore the VFSOPS. At the top level, we have a "file". In user space, this is an "fd" -- a "file descriptor object". This object is an index. Starting with the process, we see that there is a pointer in called p_fd: STRUCTURE: struct proc DEFINED: /usr/include/sys/proc.h MEMBERS: p_fd DEFINITION: The p_fd member is a pointer to a struct filedesc, which is the list of files open by the process. >From there, we can see what a filedesc is: STRUCTURE: struct filedesc DEFINED: /usr/include/sys/filedesc.h MEMBERS: fd_ofiles DEFINITION: The fd_ofiles member is a pointer to a list of struct file pointers that represent the list of files open in a process. So to get to the actual struct file for any user space descriptor, we dereference the current process (called "curproc" here, for convenience), get the p_fd member, get the list of open struct file pointers, and index it by the descriptor number: curproc->p_fd->fd_ofiles[ fd]; This gives us a pointer to the struct file associated with the open file. We are interested in three fields: STRUCTURE: struct file DEFINED: /usr/include/sys/file.h MEMBERS: f_type f_ops f_data DESCRIPTION: The f_type field specifies the type of the file descriptor (in the kernel, we call a "struct file" a descriptor; this is somewhat confusing if you are used to user space calling an fd a descriptor) can be one of: DTYPE_VNODE A vnode, which is to say, the f_data member points to a vnode and the f_ops member points to the struct fileops vnops, which is defined in /sys/kern/vfs_vnops.c DTYPE_SOCKET A socket, which is to say the f_data member points to a struct socket and the f_ops member points to the struct fileops socketops, which is defined in /sys/kern/sys_socket.c DTYPE_PIPE A pipe, which is to say, the f_data member points to a struct pipe and the f_ops member points to the struct fileops pipeops, which is defined in /sys/kern/sys_pipe.c DTYPE_FIFO A FIFO, which is to say, the f_data member points to a struct socket and the f_ops member points to the struct fileops socketops, which is defined in /sys/kern/sys_socket.c We should note at this point that the existance of the struct fileops is a kludge. It exists because the VFS layer was not completely and correctly integrated in the 4.4BSD-Lite/4.4BSD-Lite2 code. It is the fact that the struct socket (defined in /usr/include/sys/socketvar.h) and the struct pipe (defined in /usr/include/sys/pipe.h), combined with the lack of accessor functions in struct fileops, which defines only read/write/ioctl/poll entry points, a subset of the system call interface, that it is impossible to do things like file locking on sockets or credential management on pipes, etc.. Now the intersting part here is the DTYPE_VNODE value for f_data, in which case the struct fileops entries map to VOP_ calls... the VNOPS with which we are interested, and in which they operate against the vnode itself. Note: There are many system calls that are not covered by the struct fileops functions -- the read/write/ioctl/poll entry points, noted above. Such calls *directly* test to see if f_type is DTYPE_VNODE, and if it is not, fail the call immediately. otherwise they make appropriate VOP_ calls to implement the action requested by the user process. See /sys/kern/vfs_syscalls.c for more details. Note: It may seem like the struct file is the only VFS/vnode consumer; it isn't. Other consumers are various kernel interfaces, execution class loaders for loading FreeBSD native and emulated binary types, and other direct VFS consumers, like the NFS server software. It only seems that the struct file is the only consumer because of poor architectural abstraction (Some Pigs Are More Equal Than Others). So now on to answering the original question... why is there a deadfs? If we look at the vnode structure, we see a pointer to the VOP_ calls in the member v_op: STRUCTURE: struct vnode DEFINED: /usr/include/sys/vnode.h MEMBERS: v_op DEFINITION: The v_op file is the vnode operations vector; it is a pointer to a structure that contains the addresses of int pointers to functions that take opaque void * descriptor arguments -- in other words, a pointer to an array of vop_t's. Now let's say that we decide a particular vnode is no longer valid; if that vnode is referenced by an open file in user space, we now have a problem: we are trying to invalidate the vnode itself, but we don't know what f_data members of what kernel descriptors are pointing to it on behalf of files opened by what processes. We have a conundrum: how do we invalidate a vnode, such that the next reference to the vnode fails gracefully, and causes the upper level code to recognize that the underlying object is invalid, and, hopefully, destroy the reference? If only we could do this, then we will eventually work our way down to zero references, at which time the system can reclaim the vnode object back to the system vnode pool. The way we do this is we call VOP_REVOKE, which falls all the ways down to the default code in /sys/kern/vfs_default.c (which is a blatant failure to implement the Heidemann stacking framework correctly, but one which we will not get into here because we are interested in the reason for deadfs, not "why FreeBSD VFS stacking doesn't work right"), and calls the generic vop_revoke() in the file /sys/kern/vfs_subr.c. This results in vclean() (in the same file) setting v_op to dead_vnodeop_p... in other words, marking the vnode "dead", so that no further operations against it will call the real filesystem functions, but will instead fail all the way back to the point that the references can be deleted. And that's what deadfs is for: post invalidation because FreeBSD doesn't have the integration it should to remove the need for the struct fileops bypass, and because the open file instances are not reverse linked so that the objects pointing to vnodes can have their pointers invalidated, and because the model insists on vnode ownership by the system instead of by a particular file system, even when the particular file system architecture makes that a bad design decision. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Oct 27 15:54:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA15270 for freebsd-fs-outgoing; Tue, 27 Oct 1998 15:54:15 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from sv01.cet.co.jp (sv01.cet.co.jp [210.171.56.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA15230 for ; Tue, 27 Oct 1998 15:54:09 -0800 (PST) (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by sv01.cet.co.jp (8.8.8/8.8.8) with SMTP id XAA07005; Tue, 27 Oct 1998 23:52:18 GMT (envelope-from michaelh@cet.co.jp) Date: Wed, 28 Oct 1998 08:52:18 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: Otok Berliawan , lha@e.kth.se, freebsd-fs@FreeBSD.ORG, kom-arla@stacken.kth.se Subject: Re: deadfs in FreeBSD 3.0/current ? In-Reply-To: <199810272215.PAA08872@usr04.primenet.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 > their pointers invalidated, and because the model insists on vnode > ownership by the system instead of by a particular file system, > even when the particular file system architecture makes that a > bad design decision. It's not that bad. I think it was made for a couple of reasons: 1) Years of working on computers where memory capacity was measured in K not MB, creates a mindset where you tend to be very focused on memory utilization. 2) Paranoia that your code will never be seen by the public because it's too much like SYSV. This was done at a time when AT&T's lawyers controlled Unix. Regards, Mike Hancock To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message