MPSAFE VFS -- List of upcoming actions
Gustau Perez Querol
gperez at entel.upc.edu
Thu Jul 19 09:04:09 UTC 2012
On Wed, 18 Jul 2012 06:59:57 -0500, Chuck Burns wrote:
> On Wed, 18 Jul 2012 02:03:46 -0700
> Doug Barton <dougb at FreeBSD.org> wrote:
>
>> On 07/17/2012 22:54, Gustau Pérez i Querol wrote:
>> > In fact filesystems not particulary specific and not tied our
>> kernel
>> > would go to userspace; thinks like smbfs, nwfs, ntfs, ext2 o ext4
>> for
>> > example should be in userspace
>>
>> A big -1 here.
>>
>> The more native FS support we have the better off we are in terms of
>> both people migrating from other OS', and people who need to
>> maintain
>> compatibility with other OS'. Personally I use both msdosfs and
>> ext2fs
>> extensively for the latter purpose, and would not want to see either
>> removed.
>
> Agree with Doug. Fuse is generally much slower than native access,
> and has higher CPU cost as well. My poor athlonxp 2k+ jumps to 100%
> CPU usage when I copy files from either an ext4fuse or ntfs-3g
> filesystem to UFS. Please do not remove native access, and I would
> like to see even more native support.
I agree CPU is a concern. As I said I'd vote for a list of native and
well maintained fs' in the kernel plus the option of a well maintained
fuse support for the other fs'. I don't know the exact list, it was just
an exmample.
For example, the lingua-franca problem would end up with a well
maintained native fs. If no one volunteers, then at least there would be
the option of the userspace implementation. Let it be ntfs, ext2 or
anything else. I do prefer slower access than no access at all; e.g.: I
don't have native RW acess with NTFS today, and we're going have no
access to NTFS when the mpsafe vfs deadline arrives. At least this is my
opinion.
For fuse and cpu problems, it has many internal problem that probably
raise the CPU usage. At least I've never seen that kind of figures with
a linux machine using fuse.
Best,
Gustau
More information about the freebsd-fs
mailing list