From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: 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: Mon, 30 Nov 2015 09:59:40 -0500 [thread overview]
Message-ID: <565C645C.5030608@gmail.com> (raw)
In-Reply-To: <20151128134634.GF24333@carfax.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]
On 2015-11-28 08:46, Hugo Mills wrote:
> We've just had someone on IRC with a problem mounting their FS. The
> main problem is that they've got a corrupt log tree. That isn't the
> subject of this email, though.
>
> The issue I'd like to raise is that even with -oro as a point
> option, the FS is trying to replay the log tree. The dmesg output from
> mount -oro is at the end of the email.
>
> Now, my memory, experience and understanding is that the FS
> doesn't, and shouldn't replay the log tree on a RO mount, because the
> FS should still be consistent even without the reply, and
> RO-means-actually-RO is possible and desirable. (Compared to a
> journalling FS, where journal replay is required for a consistent,
> usable FS).
This is exactly how it should behave (being able to say that a RO mount
is really RO (if atimes aren't enabled) is a huge selling point). On a
side note, a properly designed journaling filesystem _can_ be made to
behave like this, but it makes the filesystem _really_ slow if you don't
have enough RAM to cache all the blocks modified by the journal (because
each block access has to check the journal for modifications).
>
> So, this looks to me like a regression that's come in somewhere.
I'm not sure that this ever worked the way it should. It should be
fixed regardless of what state things were however.
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]
next prev parent reply other threads:[~2015-11-30 14:59 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 [this message]
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
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=565C645C.5030608@gmail.com \
--to=ahferroin7@gmail.com \
--cc=hugo@carfax.org.uk \
--cc=linux-btrfs@vger.kernel.org \
/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.