All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Anton Mitterer <calestyo@scientia.net>
To: Eric Sandeen <sandeen@redhat.com>,
	Chandan Rajendra <chandan@linux.vnet.ibm.com>
Cc: Qu Wenruo <quwenruo@cn.fujitsu.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: Introduce new mount option to disable tree log replay
Date: Mon, 07 Dec 2015 21:54:44 +0100	[thread overview]
Message-ID: <1449521684.6881.13.camel@scientia.net> (raw)
In-Reply-To: <5665C1F2.8020407@redhat.com>

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

On Mon, 2015-12-07 at 11:29 -0600, Eric Sandeen wrote:
> FWIW, new mount options and their descriptions should be added to
> BTRFS-MOUNT(5) 
> as well.
Also, from the end-user perspective, there should be:
1) another option like (hard-ro) which is defined to imply any other
options that are required to make a mount truly read-only (i.e. right
now: ro and nologreplay... but in the future any other features that
may be required to make read-only really read-only).

and/or

2) a section that describes "ro" in btrfs-mount(5) which describes that
normal "ro" alone may cause changes on the device and which then refers
to hard-ro and/or the list of options (currently nologreplay) which are
required right now to make it truly ro.


I think this is important as an end-user probably expects "ro" to be
truly ro, so if he looks it up in the documentation (2) he should find
enough information that this isn't the case and what to do instead.
Further, as one might expect that in the future, other places (than
just the log) may cause changes to a device, even though mounted ro...
I think it's better for the end user to also have a real "hard-ro" like
option, than a possibly growing list of "noXYZ" where the end-user may
have no clue that something else is now also required to get the truly
read-only behaviour.


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5313 bytes --]

  reply	other threads:[~2015-12-07 20:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-07  6:06 [PATCH] btrfs: Introduce new mount option to disable tree log replay Qu Wenruo
2015-12-07 15:38 ` Chandan Rajendra
2015-12-07 23:51   ` Qu Wenruo
2015-12-07 16:27 ` Eric Sandeen
2015-12-07 16:52   ` Chandan Rajendra
2015-12-07 17:29     ` Eric Sandeen
2015-12-07 20:54       ` Christoph Anton Mitterer [this message]
2015-12-07 23:06         ` Eric Sandeen
2015-12-08  0:00           ` Christoph Anton Mitterer
2015-12-08 12:15           ` Austin S Hemmelgarn
2015-12-08 19:20             ` Christoph Anton Mitterer
2015-12-08 20:29               ` Austin S Hemmelgarn
2015-12-07 16:36 ` Austin S Hemmelgarn
2015-12-08  6:08   ` Qu Wenruo
2015-12-08 12:16     ` Austin S Hemmelgarn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1449521684.6881.13.camel@scientia.net \
    --to=calestyo@scientia.net \
    --cc=chandan@linux.vnet.ibm.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo@cn.fujitsu.com \
    --cc=sandeen@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.