[lkml]   [2008]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] ext3/jbd, kernel 2.6.13, make ext3 mountable as ext2 when journal is empty.
    Thank you for your reply!

    On 7/9/08, Theodore Tso <> wrote:
    > 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.

    First of all, I totally agree that this should never be default. The
    patch is usefull for us because the SD-card with ext3 file system is
    (possibly unsafely) pulled out of our TomTom device (which is built
    into a car) and then inserted in a Windows PC which only supports
    ext2. We are also considering ext3 on Windows or running e2fsck to
    replay the journal and then continue as ext2. But for now we are
    accessing the file system as ext2.

    > > 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....

    To run the journal, a user has to go from his PC to his car which is
    kind of hard to explain. We are aware of the fact that there are many
    SD-cards that can get corrupted due to power failure. We are only
    using SD-cards that do not exhibit this problem. So on the embedded
    device we have both the SD-card and the file system power fail
    safeness covered. The solution passes extensive power fail safe

    > > 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.

    The amount of writing is indeed limited. We actually considered
    unmounting and then mounting again but dropped that idea because we do
    not want to close files that are opened for reading. I thought that
    remounting ro did not flush the journal and reset the INCOMPAT_RECOVER
    flag. I will experiment with remounting, thanks!

    Best regards,

    Jan Willem

     \ /
      Last update: 2008-07-09 23:07    [W:0.025 / U:4.708 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site