Thread (6 messages) 6 messages, 2 authors, 2012-02-17

Re: [PATCH 2/2] misc: Add fuse2fs, a FUSE server for e2fsprogs

From: Darrick J. Wong <hidden>
Date: 2012-02-17 18:51:59

On Fri, Feb 17, 2012 at 10:18:40AM -0500, Ted Ts'o wrote:
On Sat, Jan 07, 2012 at 12:55:35AM -0800, Darrick J. Wong wrote:
quoted
This is the initial implementation of a FUSE server based on e2fsprogs.  The
point of this program is to enable ext4 to run on any OS that FUSE supports
(and doesn't already have a native driver), such as MacOS X, BSDs, and Windows.
The code requires FUSE API v28, which is available in Linux fuse and osxfuse
releases that are available as of January 2012.

Signed-off-by: Darrick J. Wong <redacted>
So my system supports up to FUSE API v26 (this is an Ubuntu 10.04
system; the same should be true for RHEL 5 and RHEL 6 as I understand
things, since fuse 2.7 and 2.8 both stayed at the same API level).
Nothing blew up when I built fuse2fs with this version of fuse, and
when I mounted it, it (mostly) seemed to work --- except it corrupted
some files randomly, and ultimately corrupted the file system itself.

I don't know yet whether this is due to the FUSE API mismatch, or some
bugs in fuse2fs, but either way, this is scary, especially since all
of the failures were silent until the data and file system corruption
happened.

Do you know why the code requires FUSE API v28, and not FUSE API v26,
and is there an explicit way (either at run time or at compile time)
to determine if there is an API mismatch?
Hrmm... it worked fine on my Ubuntu 10.04 system... :/

The reason that I specified v28 is that osxfuse advertises v28 support, and it
didn't seem to break on Linux, at least not for me.  There's nothing about v28
that mandates its use over v26.  I think the API detection is keyed off the
#define FUSE_USE_VERSION 28 at the beginning of e2fuse.c; if you try to build
against an old version it'll fail.  I'm not whether or not the wire protocol
actually checks the version, though there seem to be the appropriate fields in
the packet structs.

If you send me more data on the corruption I can try to figure out if it's some
sort of API mismatch, or e2fsprogs bugs, or e2fuse bugs.  Regrettably, it /is/
easier to corrupt something with e2fuse than it ought to be.

--D
I'm going to hold off on including this patch for now, for the obvious
reasons....

Thanks,

						- Ted
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help