point.
The new "-N" option does a forced dismount of an NFS mount point, but avoids
doing any checking of the mounted-on path, so that it will not get hung
when a vnode lock is held by another hung process on the mounted-on vnode.
The most common case of this is a "umount" with the "-f" option.
Other than avoiding checking the mounted-on path, it performs the same
forced dismount as a successful "umount -f" would do.
This commit includes a content change to the man page.
Tested by: pho
Reviewed by: kib
MFC after: 2 weeks
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D11735
Renumber cluase 4 to 3, per what everybody else did when BSD granted
them permission to remove clause 3. My insistance on keeping the same
numbering for legal reasons is too pedantic, so give up on that point.
Submitted by: Jan Schaumann <jschauma@stevens.edu>
Pull Request: https://github.com/freebsd/freebsd/pull/96
any open vnodes before proceeding. Make autounmound(8) use this flag.
Without it, even an unsuccessfull unmount causes filesystem flush,
which interferes with normal operation.
Reviewed by: kib@
Approved by: re (gjb@)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D7047
ID for each file system in addition to the normal information.
In umount(8), accept filesystem IDs as well as the usual device and
path names. This makes it possible to unambiguously specify which
file system is to be unmounted even when two or more file systems
share the same device and mountpoint names (e.g. NFS mounts from
the same export into different chroots).
Suggested by: Dan Nelson <dnelson@allantgroup.com>
- Completly changed the internals of umount(8). We do three
checks now to see if 'argv' is in the mounttable. It they
all fail, we return to main and print a warning.
- fixed the umount mount-order. The checks are rather complex
to do this. Cause umount(8) should also be able to unmount
several devices at once ('umount -a', 'umount -A',
'umount /mnt /mnt2'), the mount-order get's important.
I added checks to mark and unmark already unmounted devices.
- Various fixes with nfs-unmounts (no rpc-calls were done,
or they were done although there was an existing mount).
Since we allow overlay-mounts, we should also handle them
properly.
- Translate the deprecated nfs-syntax with '@' to ':' like
mount_nfs does. The ':' syntax has now precedence, but '@'
still works.
- 'umount -v' is now fixed for all cases and doesn't print
garbage like two times the mountpoint etc.
- removed non documented and useless umount '-F'.
- hanged nfsmounts can now unmounted 'without' any problems.
I've removed stat() and realpath() checks on the mountpoint.
Instead we just do a realpath() on the basedir of the
mountpath and add the dirname again.
Implemented this as an idea from phk. But there are still
vfs-restrictions if the nfs_mount is busy. If there are
unwritten metadata on a hanged nfs-mount, and we modify
nfs_vfsops.c to not return EBUSY, we get a deadlock :(
The problem has now moved from userland to kernel.
- removed the BUGS part from the umount(8) manpage.
- Converted it to ANSI C (more than 60% of the code have
changed).
Martin_Blapp
Fixed PR's
----------
o [1999/02/03] bin/9893 NFS umount of regular file impossible
s [1995/11/27] bin/841 stale nfs mounts cannot be umounted
o [1999/08/01] bin/12911 alfred NFS umounts are not properly done
if just the mountpoint gets umounted
Only partially solved:
----------------------
The problem is now in kernel:
o [1999/04/07] bin/11005 `umount -f' does not work if the
NFS-server is down.
PR: bin/9893 bin/841 bin/12911 bin/11005
Submitted by: Martin Blapp <mb@imp.ch>
- use new getvfsbyname() interface.
- new -A option, like -a except only mounted file systems are unmounted.
All non-cosmetic FreeBSD changes in umount.c, except ignoring of
realpath() failures, went away because they are done better in Lite2.
realpath() failures must be ignored so that non-pathnames like
"<above>:/foo" and "host:/bar" get as far as mount(2).
Reviewed by: dfr
/sbin/umount does not return the correct exit status due to incorrect
logic in its internals.
Further, because of the nature of the code, you *cannot* use it to
umount a directory from a union mountpoint. Well, you can sometimes,
it depends on if the directory is at the top of the union stack or not :)
Submitted by: njw@cs.city.ac.uk (Nick Williams)
