All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Jan Willem van den Brand <janwillem.dev@googlemail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC] ext3/jbd, kernel 2.6.13, make ext3 mountable as ext2 when journal is empty.
Date: Wed, 9 Jul 2008 12:27:15 -0400	[thread overview]
Message-ID: <20080709162715.GC11797@mit.edu> (raw)
In-Reply-To: <c56f29cb0807090824k727b0da7se1a019394cdbeea7@mail.gmail.com>

On Wed, Jul 09, 2008 at 05:24:25PM +0200, Jan Willem van den Brand wrote:
> This patch makes ext3 mountable as ext2 even in case of a power
> failure while mounted as ext3. We have tested it for kernel 2.6.13 but
> it should be fairly easy to get it to work for other versions.

What's the rationale for doing this.  Why is it *useful* to have the
filesystem be mountable as ext2 in case of a power failure?  The whole
point of ext3 is to be able to keep the filesystem consistent in case
of a power failure.

So the patch as given would never go into the kernel as-is, and in the
general case it is totally counterproductive.  Maybe it could go in as
a optional behaviour enabled by a mount option, but that's assuming we
can be convinced it's a good idea.

> In case of a power failure, the INCOMPAT flag is not reset. Systems
> that suffer from frequent power failure (e.g. SD-cards that are
> unsafely removed) will often not be mountable as ext2.

So what?  Why can't you just run the journal and check the filesystem
for consistency?  If the user did a hot-eject while the SD-card was
being written, even with your patch there is no guarantee that the
card will even be readable.  Some SD-cards go totally non-functional
due to corruption at the flash translation layer when they are yanked
in the middle of an update....

> Obviously, this solution will result in poor performance when many
> small files are frequently closed after write but that is not the case
> in our system (TomTom navigation device).

How often does your TomTom device need to update files?  A better
(userspace-only) solution might be keep the filesystem mounted
read-only, and when you need to write to the filesystem, turn on the
LED (which hopefully will be a hint to the users to keep their grubby
little paws off the eject button), remount it read/write, do your file
writes, then remount it read/only, and turn off the LED.

Regards,

						- Ted

  reply	other threads:[~2008-07-09 16:27 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <c56f29cb0807090821x74d0652ekc3ae4bb5725df76c@mail.gmail.com>
2008-07-09 15:24 ` [RFC] ext3/jbd, kernel 2.6.13, make ext3 mountable as ext2 when journal is empty Jan Willem van den Brand
2008-07-09 16:27   ` Theodore Tso [this message]
2008-07-09 21:04     ` Jan Willem van den Brand
2008-07-09 21:30       ` Theodore Tso
2008-07-10  7:01         ` Jan Willem van den Brand

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=20080709162715.GC11797@mit.edu \
    --to=tytso@mit.edu \
    --cc=janwillem.dev@googlemail.com \
    --cc=linux-kernel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.