Message-ID: <c56f29cb0807100001n4813df87r3da97bb9a47d23a9@mail.gmail.com>
Date:	Thu, 10 Jul 2008 09:01:34 +0200
From:	"Jan Willem van den Brand" <janwillem.dev@...glemail.com>
To:	"Theodore Tso" <tytso@....edu>,
	"Jan Willem van den Brand" <janwillem.dev@...glemail.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] ext3/jbd, kernel 2.6.13, make ext3 mountable as ext2 when journal is empty.

> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists