linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: "Jörn Engel" <joern@lazybastard.org>
Cc: Eric Sandeen <sandeen@redhat.com>,
	Phillip Susi <psusi@cfl.rr.com>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Add a norecovery option to ext3/4?
Date: Tue, 10 Apr 2007 07:27:18 -0400	[thread overview]
Message-ID: <20070410112718.GF13650@thunk.org> (raw)
In-Reply-To: <20070410072253.GA28665@lazybastard.org>

On Tue, Apr 10, 2007 at 09:22:53AM +0200, Jörn Engel wrote:
> > Under all conditions it should be safe to mount a read-only block
> > device, but that is not the same as mounting a filesystem read-only.
> 
> In particular, it is a lame excuse when this claim is true.  If the
> block-device is read-only, then journal replay will not work as expected
> and all the "not so easy" work has to be done anyway.
> 
> Did I miss anything?  Is it actually easier to mount a read-only device
> with unclean journal than mounting a read-write device and not replay
> the journal?

The problem is that ext3 defers writes even more than ext2 did in
order to make journalling (a) possible, and (b) more efficient.  So if
you mount the filesystem read-only without replaying the journal, you
may get incorrect data; you could get data belonging to another user's
file; the kernel could detect filesystem inconsistencies and decide
that the filesystem has errors.  Now, at least in theory the kernel
will not oops when it operates on an arbitrarily corrupted filesystem
(which is what a filesystems whose journal has not been run can look
like), BUT #1, this hasn't been as well tested we would probably like,
and #2, if the filesystem is marked with an errors-behavior of "reboot
on error", then system will reboot, because that's what you asked it
to do!

I suppose what you could do is to read in the journal, and use it to
create an remapping table so that when you want to read block #5126,
and block number 5126 is in the journal, to read the journal version
of the block instead of the one on disk.  That would allow for safe
access to a filesystem being mounted read-only without the journal
being present.

Patches gratefully accepted....

						- Ted

  reply	other threads:[~2007-04-10 11:27 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-09  0:05 Add a norecovery option to ext3/4? Samuel Thibault
2007-04-09  3:24 ` Eric Sandeen
2007-04-09  3:31   ` Samuel Thibault
2007-04-09  3:42     ` Eric Sandeen
2007-04-09 14:00       ` Theodore Tso
2007-04-09  4:29   ` Brad Campbell
2007-04-09 10:14   ` Andreas Dilger
2007-04-09 13:42   ` Valdis.Kletnieks
2007-04-09 16:37   ` Jan Engelhardt
2007-04-11 20:06   ` Pavel Machek
2007-04-09 15:43 ` Phillip Susi
2007-04-09 16:20   ` Kyle Moffett
2007-04-09 17:21   ` Eric Sandeen
2007-04-10  7:22     ` Jörn Engel
2007-04-10 11:27       ` Theodore Tso [this message]
2007-04-10 12:08         ` Jörn Engel
2007-04-10 16:44           ` Matt Mackall
2007-04-10 18:54     ` Phillip Susi
2007-04-10 19:18       ` Eric Sandeen
2007-04-10 22:04         ` Phillip Susi
2007-04-11 20:09         ` Bill Davidsen
2007-04-12 13:54           ` Benny Amorsen
2007-04-15 18:49           ` Pavel Machek

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=20070410112718.GF13650@thunk.org \
    --to=tytso@mit.edu \
    --cc=joern@lazybastard.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=psusi@cfl.rr.com \
    --cc=samuel.thibault@ens-lyon.org \
    --cc=sandeen@redhat.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).