It completely unnecessarily iterates over all filesystems and happens
to be executed a lot e.g. by synth.
Reviewed by: kib
Approved by: re (gjb)
Differential Revision: https://reviews.freebsd.org/D17143
Mainly focus on files that use BSD 3-Clause license.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
Special thanks to Wind River for providing access to "The Duke of
Highlander" tool: an older (2014) run over FreeBSD tree was useful as a
starting point.
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
and uses TCP for the Unmount RPC if the mount is over TCP.
Without this patch, umount does an Unmount RPC over UDP for all NFS mounts.
Suggested by: cperciva
Reviewed by: cperciva
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D8503
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
Off by default, build behaves normally.
WITH_META_MODE we get auto objdir creation, the ability to
start build from anywhere in the tree.
Still need to add real targets under targets/ to build packages.
Differential Revision: D2796
Reviewed by: brooks imp
mount_nfs effectively uses mount protocol v3 by default already.
v1 mount protocol is being removed along with nfsv2 by a high profile NFS
appliance vendor and our legacy v1 mount protocol usage causes rpc errors.
These tools declare global variables without using the static keyword,
even though their use is limited to a single C-file, or without placing
an extern declaration of them in the proper header file.
a sync(2) syscall before unmount(2) for the "-f" case.
This avoids a forced dismount from getting stuck for
an NFS mountpoint in sync() when the server is not
responsive. With this commit, forced dismounts should
normally work for the NFS clients, but can take up to
about 1minute to complete.
PR: kern/157365
Reviewed by: kib
MFC after: 2 weeks
Since the existing implementation searches ':' backward, a path which
includes ':' could not be mounted. You can now mount such path by
enclosing an IP address by '[]'.
Though we should change to search ':' forward, it will break
'ipv6addr:path' which is currently working. So, it still searches ':'
backward, at least for now.
MFC after: 2 weeks
is all zeros. The kernel now consistently zeroes FSIDs for non-root
users, so there's no point in printing these. Also fix a misspelling
in a comment.
Submitted by: Rudolf Cejka <cejkar@fit.vutbr.cz>
Approved by: re (scottl)
a non-fsid unmount if the file system ID is all zeros. This is a
temporary workaround for warnings that occur in the vfs.usermount=1
case because non-root users get a zeroed filesystem ID. I have a
more complete fix in the works, but I won't get it done for 5.2.
and make it work more reliably in a number of cases that have
traditionally been troublesome. The new behaviour is:
1) If the filesystem can be determined by the fsid or device,
or uniquely identified by the mountpoint, then just go ahead
and call unmount(2) using the file system ID.
2) Otherwise use fstatfs(2) to resolve the path into a file system
ID (checking with stat(2) that it is a filesystem root directory).
Case 2 can potentially block if an NFS server is down, but it can
always be avoided by using an unambiguous specification. It handles
all the hard cases such as symlinks and mismatches between the mount
list and reality. For example, if a filesystem was mounted as /mnt
inside a chroot, it will show up in the mount list as /mnt, but now
you can unmount it from outside the chroot with "umount /chroot_path/mnt".
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>
of by mount point, umount had to take care not to unmount the wrong
file system if another file system was covering the requested one.
Now that the file system to unmount is specified to the kernel using
the filesystem ID, this confusion cannot occur, so remove the code
that checked for it.
system by specifying the file system ID instead of a path. Use this
by default in umount(8). This avoids the need to perform any vnode
operations to look up the mount point, so it makes it possible to
unmount a file system whose root vnode cannot be looked up (e.g.
due to a dead NFS server, or a file system that has become detached
from the hierarchy because an underlying file system was unmounted).
It also provides an unambiguous way to specify which file system is
to be unmunted.
Since the ability to unmount using a path name is retained only for
compatibility, that case now just uses a simple string comparison
of the supplied path against f_mntonname of each mounted file system.
Discussed on: freebsd-arch
mdoc help from: ru
