[PATCH manpages] umount.2: revise MNT_FORCE description.

[PATCH manpages] umount.2: revise MNT_FORCE description.

[NeilBrown]

[-- Attachment #1.1: Type: text/plain, Size: 1646 bytes --]


MNT_FORCE does not allow a busy filesystem to be unmounted.  Only
MNT_DETACH allows that.
MNT_FORCE only tries to abort pending transactions, in the hope that
might help umount not to block,

Also, other filesystems than NFS support MNT_FORCE.

Signed-off-by: NeilBrown <neilb@suse.com>
---

Explanation derived from examination of source code.
Cc to systemd devel in relation to comment I just posted:

https://github.com/systemd/systemd/commit/0c08f5cde749bd2818475e487109cd0d413452df

You may want to move the "linux version when support was added" to a
comment, or discard it.

 man2/umount.2 | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/man2/umount.2 b/man2/umount.2
index 68f76b7c6352..ccd1d07afe88 100644
--- a/man2/umount.2
+++ b/man2/umount.2
@@ -61,9 +61,17 @@ unmounts a target, but allows additional
 controlling the behavior of the operation:
 .TP
 .BR MNT_FORCE " (since Linux 2.1.116)"
-Force unmount even if busy.
-This can cause data loss.
-(Only for NFS mounts.)
+Ask the filesystem to abort pending requests before attempting the
+unmount.  This may allow the unmount to complete without waiting
+for an inaccessible server.  If, after aborting requests, some
+processes still have active references to the filesystem, the
+unmount will still fail. In Linux 4.12, only the filesystems
+9p (2.6.16),
+ceph (2.6.34),
+cifs (2.6.12),
+fuse (2.6.16),
+lustre (3.11),
+and NFS (2.1.116) respond to MNT_FORCE.
 .TP
 .BR MNT_DETACH " (since Linux 2.4.11)"
 Perform a lazy unmount: make the mount point unavailable for new
-- 
2.14.0.rc0.dirty


[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 172 bytes --]

_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [PATCH manpages] umount.2: revise MNT_FORCE description.

[Michael Kerrisk (man-pages)]

On 08/08/2017 07:49 AM, NeilBrown wrote:
> 
> MNT_FORCE does not allow a busy filesystem to be unmounted.  Only
> MNT_DETACH allows that.
> MNT_FORCE only tries to abort pending transactions, in the hope that
> might help umount not to block,
> 
> Also, other filesystems than NFS support MNT_FORCE.
> 
> Signed-off-by: NeilBrown <neilb-IBi9RG/b67k@public.gmane.org>

Thanks, Neil. Applied.

Cheers,

Michael


> ---
> 
> Explanation derived from examination of source code.
> Cc to systemd devel in relation to comment I just posted:
> 
> https://github.com/systemd/systemd/commit/0c08f5cde749bd2818475e487109cd0d413452df
> 
> You may want to move the "linux version when support was added" to a
> comment, or discard it.
> 
>  man2/umount.2 | 14 +++++++++++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/man2/umount.2 b/man2/umount.2
> index 68f76b7c6352..ccd1d07afe88 100644
> --- a/man2/umount.2
> +++ b/man2/umount.2
> @@ -61,9 +61,17 @@ unmounts a target, but allows additional
>  controlling the behavior of the operation:
>  .TP
>  .BR MNT_FORCE " (since Linux 2.1.116)"
> -Force unmount even if busy.
> -This can cause data loss.
> -(Only for NFS mounts.)
> +Ask the filesystem to abort pending requests before attempting the
> +unmount.  This may allow the unmount to complete without waiting
> +for an inaccessible server.  If, after aborting requests, some
> +processes still have active references to the filesystem, the
> +unmount will still fail. In Linux 4.12, only the filesystems
> +9p (2.6.16),
> +ceph (2.6.34),
> +cifs (2.6.12),
> +fuse (2.6.16),
> +lustre (3.11),
> +and NFS (2.1.116) respond to MNT_FORCE.
>  .TP
>  .BR MNT_DETACH " (since Linux 2.4.11)"
>  Perform a lazy unmount: make the mount point unavailable for new
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH manpages] umount.2: restore mention of data loss with MNT_FORCE

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 1196 bytes --]


Recent patch to description of MNT_FORCE incorrectly
dropped the mention of possible data loss.  Restore it.

Signed-off-by: NeilBrown <neilb@suse.com>
---

Sorry, I thought I had put the mention of data loss back it, but clearly
not.

NeilBrown


 man2/umount.2 | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/man2/umount.2 b/man2/umount.2
index ccd1d07afe88..01f42710ee9d 100644
--- a/man2/umount.2
+++ b/man2/umount.2
@@ -63,9 +63,10 @@ controlling the behavior of the operation:
 .BR MNT_FORCE " (since Linux 2.1.116)"
 Ask the filesystem to abort pending requests before attempting the
 unmount.  This may allow the unmount to complete without waiting
-for an inaccessible server.  If, after aborting requests, some
-processes still have active references to the filesystem, the
-unmount will still fail. In Linux 4.12, only the filesystems
+for an inaccessible server, but could cause data loss.  If, after
+aborting requests, some processes still have active references to the
+filesystem, the unmount will still fail. In Linux 4.12, only the
+filesystems
 9p (2.6.16),
 ceph (2.6.34),
 cifs (2.6.12),
-- 
2.14.0.rc0.dirty


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [PATCH manpages] umount.2: restore mention of data loss with MNT_FORCE

[Michael Kerrisk (man-pages)]

On 08/10/2017 05:23 AM, NeilBrown wrote:
> 
> Recent patch to description of MNT_FORCE incorrectly
> dropped the mention of possible data loss.  Restore it.
> 
> Signed-off-by: NeilBrown <neilb@suse.com>
> ---
> 
> Sorry, I thought I had put the mention of data loss back it, but clearly
> not.

Thanks, Neil. Applied.

Cheers,

Michael


>  man2/umount.2 | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/man2/umount.2 b/man2/umount.2
> index ccd1d07afe88..01f42710ee9d 100644
> --- a/man2/umount.2
> +++ b/man2/umount.2
> @@ -63,9 +63,10 @@ controlling the behavior of the operation:
>  .BR MNT_FORCE " (since Linux 2.1.116)"
>  Ask the filesystem to abort pending requests before attempting the
>  unmount.  This may allow the unmount to complete without waiting
> -for an inaccessible server.  If, after aborting requests, some
> -processes still have active references to the filesystem, the
> -unmount will still fail. In Linux 4.12, only the filesystems
> +for an inaccessible server, but could cause data loss.  If, after
> +aborting requests, some processes still have active references to the
> +filesystem, the unmount will still fail. In Linux 4.12, only the
> +filesystems
>  9p (2.6.16),
>  ceph (2.6.34),
>  cifs (2.6.12),
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/