NFS root r/w.
The real solution would be to bring the whole nmount(2)
framework, including FS drivers and userland tools, into
a consistent state at last; but things should work in the
meantime, too.
Reported by: kris
historical relic, and are no longer appropriate for either LAN or WAN
mounting. At modern (gigabit and 10 gigabit) LAN speeds packet loss
from socket buffer fill events is common, and sequence numbers wrap
quickly enough that data corruption is possible. TCP solves both of
these problems without imposing significant overhead.
MFC after: 1 month
This is for better compatibility with other environments (Linux, Solaris,
HP-UX, AIX and Tru64 support these options).
PR: bin/109924
MFC after: 1 week
If argv[0] == "mount_nfs4", then default to mounting NFSv4,
otherwise if argv[0] == "mount_nfs", default to the old mount_nfs behavior.
- Add a -4 option.
- Add the University of Michigan copyright from mount_nfs4.c, for the
code merged from mount_nfs4.c.
Reviewed by: rees
This will allow the NFS mount code to return a string error message
in addition to returning an error integer value.
Reviewed by: mohans
MFC after: 1 month
use of the macro in sbin/mount*'s, by replacing:
mopts[] = {
MOPT_STDOPTS,
{ NULL }
}
With:
mopts[] = {
MOPT_STDOPTS,
MOPT_NULL
}
This change will help to reduce the situation that we don't explicitly
initialize "struct mntopt"'s. It should not contribute to any
functional/logical changes as far as I can tell.
in /etc/fstab. This isn't a real fix though and I'm still not sure
why it started failing. mount(8) breaks up the nfs args into seperate
repeated '-o option=value' arguments. But, the altflags variable that
we use to track things is incrementally built up each time we see the
next option and shows us the cumulative set of flags, not just the
flag that we are currently looking at. As a result, the strstr hack
for looking up flags in a giant -o opt=val,opt=val, etc string was failing
and causing a segfault. I do not know what changed recently that caused
this to suddenly break, but the code has been rather bogus for some time.
remove all the code which was trying to do so.
This code was nasty in several ways, it was hiding
the kernel bug where the kernel was unable to properly
load a module, and it was quitting if it wasn't able
to load the module. The consequence is that an ABI
breakage of the vfsconf API would have broken *every*
mount utility.
It does not help modern compilers, and some may take some hit from it.
(I also found several functions that listed *every* of its 10 local vars with
"register" -- just how many free registers do people think machines have?)
to avoid the need for rpc.lockd to perform client locks. Using
this option a user can revert back to using local locks for NFS mounts
like we did before we had rpc.lockd.
forever by default. This matches what mount_nfs did before revision
1.40, and it is the generally expected behaviour for NFS mounts.
Document the current defaults near the start of the man page and
mention the options that can be used to change them.
Discussed on: -hackers
to give up after one attempt unless a background mount is requested.
Background mounts would retry 10000 times (at least 7 days) before
giving up.
For some situations such as diskless terminals, an NFS filesystem
may be critical to the boot process, so neither the "try once" nor
background mounts are appropiate. To cater for this situation,
unbreak the -R (retry count) parameter so that it also works in
the non-background case. Interpret a zero retry count as "retry
forever".
The defaults are now "try once" for non-background mounts and "retry
forever" for background mounts; both can be overridden via -R.
Add a description of this behaviour to the manpage.
