mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Jan Willem van den Brand" <janwillem.dev@googlemail.com>
To: "Theodore Tso" <tytso@mit.edu>,
	"Jan Willem van den Brand" <janwillem.dev@googlemail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC] ext3/jbd, kernel 2.6.13, make ext3 mountable as ext2 when journal is empty.
Date: Thu, 10 Jul 2008 09:01:34 +0200	[thread overview]
Message-ID: <c56f29cb0807100001n4813df87r3da97bb9a47d23a9@mail.gmail.com> (raw)
In-Reply-To: <20080709213048.GC8517@mit.edu>

> Ah, that was the missing piece.  You have an ext2-only driver under
>  Windows, and the SD card has to be usable there.  It makes *much* more
>  sense now.  :-)

Actually, we have a different situation. I left out this part in my
explanation because I did not want to confuse people :).  But here it
goes. The SD-card is formatted with the FAT file system which has an
ext3 formatted loop file. In this way, the SD-card is "mounted" by
windows without the need for a driver. Our Windows application
accesses the loop file and only supports ext2. The embedded device
does all his writing in the loop file to ensure power fail safeness.

Initially, the solution did not pass our power fail tests. The problem
was in the page cache reordering. We have the following situation:

user | ext3 | loop | FAT | disk

The ext3 file system writes in the page cache but ensures that
ordering constraints are obeyed. By default, loop writes directly in
the page cache of the FAT file. The pages are then written out of
order to disk, disobeying the ext3 ordering constraints. Enforcing
ordered page writes by mounting the underlying file system (FAT) in
sync mode did not work because loop.c writes directly in the page
cache. We solved this by not writing directly in the page cache in
loop.c if the underlying file system is mounted in sync mode.

This solution passes our power fail tests. I will share this patch in
a new post.

>  I'll note that the code to run the journal is available in userspace,
>  and while I didn't originally write it so I can only offer it to you
>  under GPL, it wouldn't be that hard to make it work under Windows.  At
>  various times I've taken patches to make parts of e2fsprogs work under
>  Windows.  (In fact, the original version of resize2fs was paid for by
>  the folks who make PartitionMagic program, and helped pay for the down
>  payment on my house.  :-) Check out lib/ext2fs/dosio.c in the
>  e2fsprogs sources.  I don't think anyone has tried building e2fsprogs
>  on a Windows/Dos environment in quite some time, so I'm sure some
>  patches will be necessary, but it maybe quite a bit easier than you
>  think.  (As part of the PartitionMagic contract I also made parts of
>  e2fsck and mke2fs work on Windows as well, although that was over ten
>  years ago by now.)

Another solution is to compile e2fsprogs with cygwin. I actually have
compiled the latest version and it passes all tests.

>  That being said, I have to ask the question --- if the goal is Windows
>  compatibility, why aren't you using FAT?  Is the performance benefit
>  critical for your application?  Or do you need a POSIX-compliant
>  filesystem?

The embedded device has to be able to cope with power failure. FAT
becomes inconsistent after power failure. During our tests, the FAT
file system always broke in just a few power failures. Ext3 as well as
ext3 + loop (with loop patch) runs for days without breaking.

> Yes, remounting read/only will flush the journal and clear the
>  INCOMPAT_RECOVER bit.

Thanks again! I will consider this alternative.

Best regards,

Jan Willem van den Brand

      reply	other threads:[~2008-07-10  7:01 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 ` Jan Willem van den Brand
2008-07-09 16:27   ` Theodore Tso
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 [this message]

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=c56f29cb0807100001n4813df87r3da97bb9a47d23a9@mail.gmail.com \
    --to=janwillem.dev@googlemail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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

all inboxes | Powered by JetHome®