All of lore.kernel.org
 help / color / mirror / Atom feed
From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Eric Sandeen <sandeen@redhat.com>,
	Qu Wenruo <quwenruo@cn.fujitsu.com>,
	Russell Coker <russell@coker.com.au>
Cc: Chris Mason <clm@fb.com>, Hugo Mills <hugo@carfax.org.uk>,
	Btrfs mailing list <linux-btrfs@vger.kernel.org>
Subject: Re: Bug/regression: Read-only mount not read-only
Date: Wed, 2 Dec 2015 12:48:39 -0500	[thread overview]
Message-ID: <565F2EF7.5000109@gmail.com> (raw)
In-Reply-To: <565F2260.1080004@redhat.com>

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

On 2015-12-02 11:54, Eric Sandeen wrote:
> On 12/2/15 3:23 AM, Qu Wenruo wrote:
>>
>>
>> Qu Wenruo wrote on 2015/12/02 17:06 +0800:
>>>
>>>
>>> Russell Coker wrote on 2015/12/02 17:25 +1100:
>>>> On Wed, 2 Dec 2015 06:05:09 AM Eric Sandeen wrote:
>>>>> yes, xfs does; we have "-o norecovery" if you don't want that, or need
>>>>> to mount a filesystem with a dirty log on a readonly device.
>>>>
>>>> That option also works with Ext3/4 so it seems to be a standard way of
>>>> dealing
>>>> with this.  I think that BTRFS should do what Ext3/4 and XFS do in this
>>>> regard.
>>>>
>>> BTW, does -o norecovery implies -o ro?
>>>
>>> If not, how does it keep the filesystem consistent?
>>>
>>> I'd like to follow that ext2/xfs behavior, but I'm not familiar with
>>> those filesystems.
>>>
>>> Thanks,
>>> Qu
>>>
>>
>> OK, norecovery implies ro.
>
> For XFS, it doesn't imply it, it requires it; i.e. both must be stated explicitly:
>
>          /*
>           * no recovery flag requires a read-only mount
>           */
>          if ((mp->m_flags & XFS_MOUNT_NORECOVERY) &&
>              !(mp->m_flags & XFS_MOUNT_RDONLY)) {
>                  xfs_warn(mp, "no-recovery mounts must be read-only.");
>                  return -EINVAL;
>          }
>
> ext4 is the same, I believe:
>
>          } else if (test_opt(sb, NOLOAD) && !(sb->s_flags & MS_RDONLY) &&
>                     ext4_has_feature_journal_needs_recovery(sb)) {
>                  ext4_msg(sb, KERN_ERR, "required journal recovery "
>                         "suppressed and not mounted read-only");
>                  goto failed_mount_wq;
>
> so if you'd like btrfs to be consistent with these, I would not make
> norecovery imply ro; rather, make I would make it require an explicit ro, i.e.
>
> mount -o ro,norecovery
Agreed, with something like that, it should as blatantly obvious as 
possible that you can't write to the FS.

On a side note, do either XFS or ext4 support removing the norecovery 
option from the mount flags through mount -o remount?  Even if they 
don't, that might be a nice feature to have in BTRFS if we can safely 
support it.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

  reply	other threads:[~2015-12-02 17:49 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-28 13:46 Bug/regression: Read-only mount not read-only Hugo Mills
2015-11-30 14:59 ` Austin S Hemmelgarn
2015-11-30 15:28   ` Hugo Mills
2015-11-30 16:00     ` Austin S Hemmelgarn
2015-11-30 16:48 ` Chris Mason
2015-11-30 17:06   ` Hugo Mills
2015-12-01 19:00     ` Chris Mason
2015-12-01 19:05       ` Eric Sandeen
2015-12-02  6:25         ` Russell Coker
2015-12-02  9:06           ` Qu Wenruo
2015-12-02  9:23             ` Qu Wenruo
2015-12-02 16:54               ` Eric Sandeen
2015-12-02 17:48                 ` Austin S Hemmelgarn [this message]
2015-12-02 18:53                   ` Hugo Mills
2015-12-02 22:48                   ` Eric Sandeen
2015-12-02 23:40                     ` Qu Wenruo
2015-12-02 23:51                       ` Hugo Mills
2015-12-03  6:44                         ` Duncan
2015-12-04 12:32                         ` Austin S Hemmelgarn
2015-12-04 12:23                       ` Austin S Hemmelgarn
2015-11-30 17:08   ` Austin S Hemmelgarn
2015-12-01  6:46   ` Qu Wenruo
2015-12-01 18:54     ` Chris Mason
2015-12-01 23:47       ` Qu Wenruo

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=565F2EF7.5000109@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=clm@fb.com \
    --cc=hugo@carfax.org.uk \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo@cn.fujitsu.com \
    --cc=russell@coker.com.au \
    --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.