ext2fuse: user-space ext2 implementation

[Steve Franks]

On Sun, Dec 14, 2008 at 8:47 AM, Paul B. Mahol <onemda at gmail.com> wrote:
> On 12/14/08, Bruce M Simpson <bms at incunabulum.net> wrote:
>> Paul B. Mahol wrote:
>>>> Can you please relay this feedback to the authors of ext2fuse?
>>>>
>>>> As mentioned earlier in the thread, the ext2fuse code could benefit from
>>>> UBLIO-ization. Are you or any other volunteers happy to help out here?
>>>>
>>>
>>> Well, first higher priority would be to fix existing bugs. It would be
>>> very little
>>> gain with user cache, because it is already too much IMHO slow and
>>> adding user cache
>>> will not make it faster, but that is not port problem.
>>>
>>
>> I'm not aware of bugs with ext2fuse itself; my work on the port was
>> merely to try to raise awareness that a user-space project for ext2
>> filesystem access existed.
>>
>> Can you elaborate further on your experience with ext2fuse which seems
>> to you to be buggy, i.e. symptoms, root cause analysis etc. ? Have you
>> reported these to the author(s)?
>
> I have read TODO.
>
>> Have you measured the performance? Is the performance sufficient for the
>> needs of an occasional desktop user?
>
> Performance was not sufficient, and adding user cache will not improve access
> speed on first read.
> After mounting ext2fs volume (via md(4)) created with e2fsprogs port
> and copying data
> from ufs to ext2, reading was quite slow. Also ext2fuse after mount
> doesnt exits it
> is still running displaying debug data - explaining why project
> itselfs is in alpha
> state.
>
>> I realise we are largely involved in content-free argument here, however
>> the trade-off of ext2fuse vs ext2fs in the FreeBSD kernel source tree,
>> is that of a hopefully more actively maintained implementation vs one
>> which is not maintained at all, and any alternatives for FreeBSD users
>> would be welcome.
>
> Project itself doesnt look very active, but I may be wrong. It is in alpha state
> as reported on SF.
> IMHO it is better to maintain our own because it is in better shape, but I'm not
> intersted in ext* as developer.

AFAIK our ext* either barfs or corrupts ext3, and since linux is
pretty much all using ext3 these days, we're stuck in read-only for
ext3, which is rather undesirable, methinks (seems everyone's using
fuse's ntfs for this same reason [which is stable, however]).  Which
is not to say stealing the ext3 (journal?) implementation and putting
it in our code isn't a better choice, I'm just pointing out there is
no good choice right now...

Steve