Date: Tue, 21 Dec 2004 22:16:53 +0100 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Kirk McKusick <mckusick@mckusick.com> Cc: Robert Watson <rwatson@freebsd.org> Subject: Re: Forcefully unmounting devfs... Message-ID: <84301.1103663813@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 21 Dec 2004 12:29:00 PST." <200412212029.iBLKT05S044869@beastie.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?84301.1103663813>