Commit Message

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 <djwong@us.ibm.com>
---
MCONFIG.in | 1
configure | 89 +++
configure.in | 9
misc/Makefile.in | 14
misc/fuse2fs.c | 1747 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 1858 insertions(+), 2 deletions(-)
create mode 100644 misc/fuse2fs.c
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Comments

On Sat, Jan 07, 2012 at 12:55:35AM -0800, Darrick J. Wong wrote:
> 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 <djwong@us.ibm.com>
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?
I'm going to hold off on including this patch for now, for the obvious
reasons....
Thanks,
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

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:> > 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 <djwong@us.ibm.com>> > 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>
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html