From: Karel Zak <kzak@redhat.com>
To: Eric Sandeen <sandeen@redhat.com>
Cc: Qu Wenruo <quwenruo@cn.fujitsu.com>,
fsdevel <linux-fsdevel@vger.kernel.org>,
btrfs <linux-btrfs@vger.kernel.org>,
linux-ext4@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: Ideas on unified real-ro mount option across all filesystems
Date: Thu, 17 Dec 2015 15:08:58 +0100 [thread overview]
Message-ID: <20151217140858.GD13224@ws.net.home> (raw)
In-Reply-To: <567228EF.80007@redhat.com>
On Wed, Dec 16, 2015 at 09:15:59PM -0600, Eric Sandeen wrote:
> I have always interpreted it as simply "no user changes to the filesystem,"
> and that is clearly what the vfs does with the flag...
Yep,
> Given that nothing in the documentation implies that the block device itself
> must remain unchanged on a read-only mount, I don't see any problem which
> needs fixing. MS_RDONLY rejects user IO; that's all.
I agree, it's FS specific business to interpret the 'ro'.
And it's already enough complicated, we have three levels of "read-only":
- read-only device (blockdev --setro ioctl)
- read-only filesystem (mount -o ro)
- read-only VFS node (mount -o remount,ro,bind /src /dst)
and for example in /proc/self/mountinfo we distinguish between FS "ro"
and VFS "ro" flag:
# grep test /proc/self/mountinfo
185 59 8:5 / /mnt/test ro,relatime shared:32 - ext4 /dev/sda5 rw,data=ordered
^^ ^^
BTW, util-linux 2.27 mount(8) man page:
-r, --read-only
Mount the filesystem read-only. A synonym is -o ro.
Note that, depending on the filesystem type, state and
kernel behavior, the system may still write to the device. For
example, ext3 and ext4 will replay the journal if the
filesystem is dirty. To prevent this kind of write access, you
may want to mount an ext3 or ext4 filesystem with the ro,noload
mount options or set the block device itself to read-only
mode, see the blockdev(8) command.
(maybe we need to copy this note to "ro" description too and add hint
about btrfs too :-)
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
next prev parent reply other threads:[~2015-12-17 14:09 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-17 1:41 Ideas on unified real-ro mount option across all filesystems Qu Wenruo
2015-12-17 1:58 ` Qu Wenruo
2015-12-17 3:15 ` Eric Sandeen
2015-12-17 3:26 ` Darrick J. Wong
2015-12-17 14:08 ` Karel Zak [this message]
2015-12-18 1:29 ` Qu Wenruo
2015-12-18 2:01 ` Christoph Anton Mitterer
2015-12-18 2:51 ` Eric Sandeen
2015-12-18 4:20 ` Christoph Anton Mitterer
2015-12-22 1:32 ` Kai Krakow
2015-12-22 12:41 ` Austin S. Hemmelgarn
2015-12-23 23:22 ` Stewart Smith
2015-12-26 22:53 ` Dave Chinner
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=20151217140858.GD13224@ws.net.home \
--to=kzak@redhat.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=quwenruo@cn.fujitsu.com \
--cc=sandeen@redhat.com \
--cc=xfs@oss.sgi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).