linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Kai Krakow <hurikhan77@gmail.com>, linux-btrfs@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: Ideas on unified real-ro mount option across all filesystems
Date: Tue, 22 Dec 2015 07:41:04 -0500	[thread overview]
Message-ID: <567944E0.6040908@gmail.com> (raw)
In-Reply-To: <20151222023221.56a89345@jupiter.sol.kaishome.de>

On 2015-12-21 20:32, Kai Krakow wrote:
> Am Fri, 18 Dec 2015 03:01:06 +0100
> schrieb Christoph Anton Mitterer <calestyo@scientia.net>:
>
>> The manpage says:
>>> ro     Mount the filesystem read-only.
>>> rw     Mount the filesystem read-write.
>
> That means: the filesystem... Not the block device...
No, that means: That particular instantiation of the VFS layer to access 
the filesystem.
Not the filesystem (the filesystem is the data and metadata on disk), 
not the block device (which is an abstraction used as a container for 
the filesystem).
>
> Sorry, it's kinda nitpicking. But actually, the file system IS
> read-only: You cannot modify files from user's view.
 From a non technical view point, yes, that is correct; until you have 
undetected corruption in the journal or log or whatever other structure 
is used for consistency, at which point it isn't read-only because the 
filesystem just changed by virtue of you mounting it (and even without 
that type of corruption, stuff gets changed on a 'read-only' mount 
regardless in many filesystems, many of them track when the filesystem 
was last mounted, how many times it's been mounted, and other similar 
things).
>
> What you actually want is not modifying the underlying storage which is
> the block device and includes stuff like meta and journal data (which
> is only indirectly visible to users at best).
No, the metadata and journal are a integral part of the filesystem 
itself.  Without those, there is no filesystem.  That and the metadata 
_is_ directly visible to the user, in the form of directory structure, 
stat(), output from lsattr, and even stuff like FIEMAP and filefrag.

The filesystem _is_ the data and metadata on disk, as such, the 
filesystem being read-only means that none of that data or metadata 
should change.
>
> You can argue that man pages are not particularly end-user friendly.
> But for an admin this makes sense without being an fs developer.
That really depends.  I'm not a FS developer, but I still expect when I 
see 'read-only' that it means the same as 'immutable for everything 
managed by that particular object that has been made read-only, for all 
access methods through that object'.  And while I bet most 
administrators wouldn't use quite the same terminology, I would be 
willing to bet that many of them have essentially the same expectation 
unless specifically told otherwise on a case-by-case basis.

  reply	other threads:[~2015-12-22 12:41 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
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 [this message]
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=567944E0.6040908@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=hurikhan77@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@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 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).