public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Robert Hancock <hancockrwd@gmail.com>
To: porte64@free.fr
Cc: linux-kernel@vger.kernel.org
Subject: Re: read-only partitions: does the policy apply to all metadata ?
Date: Tue, 10 Mar 2009 17:33:51 -0600	[thread overview]
Message-ID: <49B6F8DF.9040409@gmail.com> (raw)
In-Reply-To: <355270241.1702481236702404399.JavaMail.root@spooler8-g27.priv.proxad.net>

porte64@free.fr wrote:
> Hello,
> 
> When a partition is mounted as read-only, does the kernel
> really prevent ANY byte to be written to it, including
> any metadata ?
> 
> (i am thinking here about file attributes -- last access time,
> as well as meta information about filesystem/blocks
> description etc ...).

As far as I know any of the visible attributes (last access, etc.) 
cannot be modified. However, mounting read-only may still write to the 
filesystem if the block device is writable, for example with ext3/ext4 
if the file system was not unmounted cleanly last time and the journal 
needs to be replayed.

> 
> And is the policy implemented in every filesystem type driver
> or at some abstraction level (as if the write() and like
> system calls were designed to return an error).
> 
> Unfortunately, on common (all?) hard drives, there seems
> to be no switch to set the device microcode in read-only
> mode.
> 
> By the way, this makes me also thing about memory cards
> with locks: is it a real protection or it is just a setting
> which tells the kernel that it *SHOULD* mount the device
> read-only ?

Normally the card reader indicates to the OS that the device is 
read-only, and then the kernel will mount it only read-only. However, 
note that some crappy SD card readers don't implement the write protect 
switch detection and will allow writing to a card marked read-only.

> 
> Please include my private address if you answer; i posted to the
> list because in some other forums we did not come up
> with a clear answer, so this is my last chance to get a
> definite done. However i didn't subscribe to the list as
> i have realized i am not able to help unfortunately:
> operating systems are the most complex thing ever design by humans !
> 
> Best regards
> Phil


  parent reply	other threads:[~2009-03-10 23:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-10 16:26 read-only partitions: does the policy apply to all metadata ? porte64
2009-03-10 17:22 ` Valdis.Kletnieks
2009-03-10 17:34   ` Alan Cox
2009-03-10 18:08     ` Valdis.Kletnieks
2009-03-15 21:17     ` Pavel Machek
2009-03-10 23:33 ` Robert Hancock [this message]
2009-03-12  8:55   ` porte64

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=49B6F8DF.9040409@gmail.com \
    --to=hancockrwd@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=porte64@free.fr \
    /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