From owner-freebsd-arch@FreeBSD.ORG  Tue Dec 21 21:32:40 2004
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 6551A16A4CE; Tue, 21 Dec 2004 21:32:40 +0000 (GMT)
Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id D83FE43D39; Tue, 21 Dec 2004 21:32:39 +0000 (GMT)
	(envelope-from scottl@freebsd.org)
Received: from [192.168.254.12] (g4.samsco.home [192.168.254.12])
	(authenticated bits=0)
	by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id iBLLa2ii079988;
	Tue, 21 Dec 2004 14:36:03 -0700 (MST)
	(envelope-from scottl@freebsd.org)
Message-ID: <41C89672.3000808@freebsd.org>
Date: Tue, 21 Dec 2004 14:32:34 -0700
From: Scott Long <scottl@freebsd.org>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
	rv:1.7) Gecko/20040514
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
References: <84301.1103663813@critter.freebsd.dk>
In-Reply-To: <84301.1103663813@critter.freebsd.dk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org
cc: Kirk McKusick <mckusick@mckusick.com>
cc: arch@freebsd.org
cc: Robert Watson <rwatson@freebsd.org>
Subject: Re: Forcefully unmounting devfs...
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussion related to FreeBSD architecture
	<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Dec 2004 21:32:40 -0000

Poul-Henning Kamp wrote:

> In message <200412212029.iBLKT05S044869@beastie.mckusick.com>, Kirk McKusick wr
> ites:
> 
> 
>>Poul-Henning is correct. To elaborate, the operations vector for device
>>vnodes have historivcally been built up from a mix of specfs opertions
>>which deal with the mechanics of doing I/O (read, write, strategy, ioctl,
>>etc) and the containing filesystem (UFS, NFS) operations for naming (open,
>>stat, chown, chmod, rename, etc). When the containing filesystem is
>>forcibly unmounted, the naming operations are stripped away leaving
>>only the I/O operations. Thus read, write, strategy, and such continue
>>to work, but name related operations on the descriptor (fstat, fchown,
>>fchmod, etc) will fail as the underlying naming operations are gone. 
>>I still believe that this is a reasonable approach as it lets things
>>like the disk continue to operate when an unmount is done.
> 
> 
> But the question in my mind is: do we really want disks/devices to
> continue working if we forcefully unmount a devfs instance ?
> 
> Today, the main if not only use for multiple devfs instances are
> chroot/jail, and if I wear my jail-warden uniform for a moment, I
> would expect that a forceful unmount of /some/jail/dev would mean
> "just kill anything that prevents me from doing a normal umount
> of this devfs instance".
> 
> Problem with that is that we get into cascading forced unmounts,
> which I in my jail warden outfit would love to just Do The Right Thing,
> but as a kernel hacker I know how many panics are just waiting for
> that to happen...
> 
> So as I see it, we have to possible ways it can work:
> 
> Either disable forceful unmount of devfs, which makes sense from
> KISS and many other principles, and then jail wardens will have to
> find other ways to clean up their jails
> 
> Or make forceful unmounts kill any process which holds it busy,
> unmount any filesystem using a device from it and then clean
> up and leave.
> 
> The one option I don't like is:  unmount and leave all sorts of stuff
> in weird intermediate states from which the administrator may not
> be able to recover.
> 
> The more I think about it, the more I lean towards the first option.
> 

I think that I'd agree here from the point of view of finding an 
expedient way to keep from shooting off feet.

Scott