From owner-freebsd-arch@FreeBSD.ORG Sat Jul 5 08:05:16 2003 Return-Path: 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 DD4BD37B401 for ; Sat, 5 Jul 2003 08:05:16 -0700 (PDT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 9292C43FCB for ; Sat, 5 Jul 2003 08:05:15 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 5 Jul 2003 16:05:14 +0100 (BST) To: "Vladimir B. Grebenschikov" In-Reply-To: Your message of "05 Jul 2003 17:57:51 +0400." <1057413470.716.3.camel@localhost> Date: Sat, 05 Jul 2003 16:05:13 +0100 From: Ian Dowse Message-ID: <200307051605.aa02337@salmon.maths.tcd.ie> cc: freebsd-arch@freebsd.org Subject: Re: Unmounting by filesystem ID X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2003 15:05:17 -0000 In message <1057413470.716.3.camel@localhost>, "Vladimir B. Grebenschikov" writ es: >May be you fix issue of umounting by known vnode ? >problem is in mounting different devices under chroot. >in list of mounts they differ only by device id, and it is rather=20 >difficult to umount filesystem if I known absolute path but do not enter >to chroot. The MNT_BYFSID approach makes it always possible to indicate to the kernel which filesystem is to be unmounted, but some more work is needed in the umount(8) utility to handle unusual cases. The simplest way for umount to reliably pick the right file system would be to have it call statfs(2) on the supplied path, and then use the resulting filesystem ID to do the unmount(2) call. That would allow you to unmount a filesystem that was mounted from within a chroot by just specifying the full path to the filesystem even though it is not the path that df or mount show. Unfortunately, statfs(2) may get stuck if the path leads to (or traverses) a network filesystem that is not responding. In this case it is better for the umount utility to use getfsstat(2) with the MNT_NOWAIT flag, and pick the filesystem that has the path that was specified. This will do the wrong thing if for example you two /var filesystems listed because one was mounted from inside a chroot. There is also the problem of checking that the path points to the root of the filesystem as statfs(2) works on any file or directory. I think umount can probably be made do something reasonable in most cases by having it use extra mechanisms such as statfs(2) only when the named filesystem is not found on the mount list, or when it is found multiple times, but it may be necessary to add a new command-line argument to force it to use one of the two behaviours. Note that you can also unmount a filesystem by specifying the device name instead of the path. This works a bit better now than it used to, as umount doesn't have to translate back into a path before calling unmount(2). However it can still get a bit confused by chroots: # chroot /root0 mdmfs -s 5m md0 /mnt # chroot /root1 mdmfs -s 5m md1 /mnt # df | grep md /dev/md0 4780 4 4396 0% /mnt /dev/md1 4780 4 4396 0% /mnt # umount /dev/md0 umount: cannot umount /mnt, /dev/md1 is mounted there, umount it first # df | grep md /dev/md0 4780 4 4396 0% /mnt /dev/md1 4780 4 4396 0% /mnt # umount -f /dev/md0 # df | grep md /dev/md1 4780 4 4396 0% /mnt # umount /dev/md1 # df | grep md # Ian