Re: Forcefully unmounting devfs...

From: Scott Long (scottl_at_freebsd.org)
Date: 12/21/04

  • Next message: Kris Kennaway: "Re: Forcefully unmounting devfs..." 
    Date: Tue, 21 Dec 2004 14:32:34 -0700
To: Poul-Henning Kamp <phk@phk.freebsd.dk>

    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
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Kris Kennaway: "Re: Forcefully unmounting devfs..."

    Relevant Pages

    • Re: Forcefully unmounting devfs...
      ... etc) will fail as the underlying naming operations are gone. ... >like the disk continue to operate when an unmount is done. ... continue working if we forcefully unmount a devfs instance? ... Either disable forceful unmount of devfs, ...
      (freebsd-arch)
    • Re: Unmounting by filesystem ID
      ... > The patch below adds a new mount flag MNT_BYFSID that can be used ... > to unmount a filesystem by specifying its filesystem ID instead of ... > filesystem got unmounted, it does not require a reboot to unmount ... this patch only affects unmounting; ...
      (freebsd-arch)
    • Re: Filesystem wont unmount
      ... Subject: Filesystem won't unmount ... Once I came across a filesystem that would not umount, ... copying of this e-mail and/or any attachments thereto, ...
      (AIX-L)
    • Unmounting by filesystem ID
      ... to unmount a filesystem by specifying its filesystem ID instead of ... filesystem got unmounted, it does not require a reboot to unmount ... -getmntname(const char *fromname, const char *onname, ...
      (freebsd-arch)
    • [PATCH] Fix dcache race during umount
      ... between unmounting a filesystem and the memory shrinker. ... prune_dcacheignoring any dentry for which the superblock is being unmounted ... that is being unmounted, and unmount will not be able to start until any such ...
      (Linux-Kernel)