From owner-freebsd-fs  Sun Jan 23 13:34:39 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 276A414D25
	for <fs@FreeBSD.ORG>; Sun, 23 Jan 2000 13:34:35 -0800 (PST)
	(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.1/8.9.1) with ESMTP id QAA18296;
	Sun, 23 Jan 2000 16:34:32 -0500 (EST)
Received: (from ezk@localhost)
	by shekel.mcl.cs.columbia.edu (8.9.1/8.9.1) id QAA28564;
	Sun, 23 Jan 2000 16:34:32 -0500 (EST)
Date: Sun, 23 Jan 2000 16:34:32 -0500 (EST)
Message-Id: <200001232134.QAA28564@shekel.mcl.cs.columbia.edu>
X-Authentication-Warning: shekel.mcl.cs.columbia.edu: ezk set sender to ezk@shekel.mcl.cs.columbia.edu using -f
From: Erez Zadok <ezk@cs.columbia.edu>
To: Chuck McCrobie <mccrobi@aplcenMP.apl.jhu.edu>
Cc: fs@FreeBSD.ORG
Subject: Re: Userfs Daemon Dies, What Happens? & Caching Questions 
In-reply-to: Your message of "Sat, 22 Jan 2000 14:32:58 EST."
             <388A05EA.E8CE2EBA@apl.jhu.edu> 
Sender: owner-freebsd-fs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

In message <388A05EA.E8CE2EBA@apl.jhu.edu>, Chuck McCrobie writes:
> I've been following the discussion about the userfs.  I'm wondering
> what happens if, while the pseudo-device is mounted, the daemon dies.
> Doesn't that tend to "fudge" up the pseudo-device?  I've only just
> started into file system implementations for FreeBSD, so sorry if the
> answer is obvious...

As the maintainer of am-utils (amd), I can tell you with confidence: you're
SOL. :-)

Seriously, user-level f/s servers should be considered system (read: kernel)
services.  What happens if a kernel module dies?  Your machine must reboot,
right?  When amd or something like it dies, it may leave an active struct
vfs mounted in the kernel, and several processes hung and un-killable (not
even -9) b/c the daemon was mounted with the "hard" option.

> It would seem that some type of recovery would be necessary for the
> new daemon when its started.

If you want to mount the new daemon on the same mnt pt, using the same
resources (such port address, etc.) then you must first umount the old hung
mnt pt.  That's usually requires a reboot.  What's needed is a
forced-unmount that will remove the in-kernel struct vfs no-questions-asked,
*and* release any resources associated with that VFS (such as hung
processes).  Some OSs have a fumount() syscall, but it doesn't do all of
that.  (A while back I've written a kmem program for sunos4 which did just
that.)

All of the problems of user-level NFS servers are fixed with autofs (at
least the latest version of it as of Solaris 2.6).

> Does the userfs handle caching of disk blocks?  Does it handle caching
> of inodes?  Does it handle caching of directory data?  If so, the userfs
> would then not benefit from the caching algorithms in the kernel?
> 
> Chuck McCrobie  (** MAD VAX **)
> mccrobi@apl.jhu.edu
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-fs" in the body of the message

Erez.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message