Re: ext2fuse: user-space ext2 implementation
Paul B. Mahol
> I have rolled a port for ext2fuse:
> http://people.freebsd.org/~bms/dump/fusefs-ext2fs.tar
Ignoring fact that is buggy, slooow and port doesnt have any cache implemented
and port leaves files behind in share/doc/ext2fuse when package
deleted it looks fine.
--
Paul
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stabl...@freebsd.org"
Bruce Simpson
> On 12/8/08, Bruce M. Simpson <b...@freebsd.org> wrote:
>
>> I have rolled a port for ext2fuse:
>> http://people.freebsd.org/~bms/dump/fusefs-ext2fs.tar
>>
>
> Ignoring fact that is buggy, slooow and port doesnt have any cache implemented
> and port leaves files behind in share/doc/ext2fuse when package
> deleted it looks fine.
>
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?
Can you elaborate further on the files being left behind by the port? I
didn't see this issue in my own testing.
thank you
BMS
Paul B. Mahol
> Paul B. Mahol wrote:
>> On 12/8/08, Bruce M. Simpson <b...@freebsd.org> wrote:
>>
>>> I have rolled a port for ext2fuse:
>>> http://people.freebsd.org/~bms/dump/fusefs-ext2fs.tar
>>>
>>
>> Ignoring fact that is buggy, slooow and port doesnt have any cache
>> implemented
>> and port leaves files behind in share/doc/ext2fuse when package
>> deleted it looks fine.
>>
>
> 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.
> Can you elaborate further on the files being left behind by the port? I
> didn't see this issue in my own testing.
It install files in this way:
test -z "/usr/local/share/doc/ext2fuse" || ./install-sh -c -d
"/usr/local/share/doc/ext2fuse"
make deinstall and pkg_delete doesnt not remove that files/dir,
--
Paul
Bruce M Simpson
>> 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)?
Have you measured the performance? Is the performance sufficient for the
needs of an occasional desktop user?
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.
thanks
BMS
Paul B. Mahol
> 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.
--
Paul
Bruce Simpson
> 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.
>
Shelved due to lack of interest, then... others can feel free to pick up.
thanks
BMS