From: Eric Sandeen <sandeen@sandeen.net>
To: Christoph Anton Mitterer <calestyo@scientia.net>,
Qu Wenruo <quwenruo@cn.fujitsu.com>,
Eric Sandeen <sandeen@redhat.com>,
fsdevel <linux-fsdevel@vger.kernel.org>,
btrfs <linux-btrfs@vger.kernel.org>,
kzak@redhat.com
Cc: 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 20:51:22 -0600 [thread overview]
Message-ID: <567374AA.6030007@sandeen.net> (raw)
In-Reply-To: <1450404066.6498.70.camel@scientia.net>
On 12/17/15 8:01 PM, Christoph Anton Mitterer wrote:
> On Fri, 2015-12-18 at 09:29 +0800, Qu Wenruo wrote:
>> 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.
>>
>> And thanks for the info provided by Karel, it's clear that at least
>> mount(8) itself already has explain on what ro will do and what it
>> won't do.
>
> I wouldn't really agree, here. At least not from the non-developer side
> (and one should hope filesystems and their manpages aren't only made
> for fs-devlopers).
>
> The manpage says:
>> ro Mount the filesystem read-only.
>> rw Mount the filesystem read-write.
>
> IMHO, that leaves absolutely unclear, what this actually means,
> especially given that most end-users will probably consider the
> filesystem and its device being basically "the same".
<lots of words snipped>
Karel pointed out that recent mount(8) says:
> -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.
which should leave nothing to the imagination.
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2015-12-18 2:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <567212DA.8050808@cn.fujitsu.com>
2015-12-17 3:15 ` Ideas on unified real-ro mount option across all filesystems Eric Sandeen
2015-12-17 3:26 ` Darrick J. Wong
2015-12-17 14:35 ` Carlos E. R.
2015-12-17 14:58 ` Carlos E. R.
2015-12-17 14:08 ` Karel Zak
2015-12-18 1:29 ` Qu Wenruo
2015-12-18 2:01 ` Christoph Anton Mitterer
2015-12-18 2:51 ` Eric Sandeen [this message]
2015-12-18 4:20 ` Christoph Anton Mitterer
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=567374AA.6030007@sandeen.net \
--to=sandeen@sandeen.net \
--cc=calestyo@scientia.net \
--cc=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