public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
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

  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