Re: [PATCH v2] btrfs: Introduce new mount option to disable tree log replay

[Chandan Rajendra <chandan@linux.vnet.ibm.com>]

On Tuesday 08 Dec 2015 14:10:33 Qu Wenruo wrote:
> Introduce a new mount option "nologreplay" to co-operate with "ro" mount
> option to get real readonly mount, like "norecovery" in ext* and xfs.
> 
> Since the new parse_options() need to check new flags at remount time,
> so add a new parameter for parse_options().
> 
> Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
> ---
> v2:
>   Make RO check mandatory for btrfs_parse_options().
>   Add btrfs_show_options() support for nologreplay.
> 
>   Document for btrfs-mount(5) will follow after the patch being merged.
> ---
>  Documentation/filesystems/btrfs.txt |  7 +++++++
>  fs/btrfs/ctree.h                    |  4 +++-
>  fs/btrfs/disk-io.c                  |  7 ++++---
>  fs/btrfs/super.c                    | 29 +++++++++++++++++++++++++----
>  4 files changed, 39 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/filesystems/btrfs.txt
> b/Documentation/filesystems/btrfs.txt index c772b47..7ad5b93 100644
> --- a/Documentation/filesystems/btrfs.txt
> +++ b/Documentation/filesystems/btrfs.txt
> @@ -168,6 +168,13 @@ Options with (*) are default options and will not show
> in the mount options. notreelog
>  	Enable/disable the tree logging used for fsync and O_SYNC writes.
> 
> +  nologreplay
> +	Disable the log tree replay at mount time to prevent devices get
> +	modified. Must be use with 'ro' mount option.
> +	A filesystem mounted with the 'nologreplay' option cannot
> +	transition to a read-write mount via remount,rw - the filesystem
> +	must be unmounted and remounted if read-write access is desired.
> +

May be the following is slightly better ...

Disable the log tree replay at mount time to prevent filesystem from getting
modified. Must be used with 'ro' mount option.  A filesystem mounted with the
'nologreplay' option cannot transition to a read-write mount via remount,rw -
the filesystem must be unmounted and mounted back again if read-write access
is desired.

Aside from above, everything else looks good to me.

Reviewed-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>

-- 
chandan