Red Hat Bugzilla – Bug 249557
bring consistency to intr mount option for all nfs flavors
Last modified: 2007-11-30 17:12:11 EST
util-linux defaults to setting the "intr" option for NFSv4 mounts. It should
default to "nointr".
This looks like it might also be an issue with later RHEL/Fedora releases and
upstream, but I need to confirm.
Created attachment 159934 [details]
upstream patch -- make mount default to nointr
Patch I plan to send upstream once I test it. It should make mount.nfs4 default
Fixing tagline. I'm morphing this ticket to track some patches that I've sent
upstream to (hopefully) make intr the default for all NFS flavors...
Created attachment 159973 [details]
patch -- make intr the default for v2/3 and fix manpage
This patch I sent upstream. It makes "intr" the default for v2/3 and fixes the
Created attachment 159974 [details]
patch -- make string-based mount options default to "intr"
This patch makes "intr" the default when using string-based mount options on
the latest upstream kernels.
Upstream comments seem to indicate that defaulting to "intr" might be
problematic. If a close call is interrupted during the sync, then the close can
return EINTR without actually syncing the file out to the server. The file is
still closed, however and locks are released. This can lead to data corruption.
There was a bit of discussion around ways to avoid this, but for the time being
"nointr" should probably be the default.
It looks like the string-based mount options already are going to default to
nointr for nfs4. The question here is whether we want to fix struct based mount
options to do the same. Since that will hopefully just go away eventually, it
may be best to just not worry about it.
Chuck Lever's doing a number of mount.nfs cleanups upstream and seems to be
looking at this as well. I'll leave this in his hands for now. It's unlikely
that we'd want to change RHEL's behavior anyway...