Re: MPSAFE VFS -- List of upcoming actions

On 7/21/12, Antony Mawer <lists_at_mawer.org> wrote:
> On Wed, Jul 18, 2012 at 6:45 PM, Attilio Rao <attilio_at_freebsd.org> wrote:
>> 2012/7/18, Gustau Pérez i Querol <gperez_at_entel.upc.edu>:
>>>
>>>     Sorry fo the delay.
>>>
>>>     About the ntfs support, I'd go with fuse and leave the most relevant
>>> filesystems in kernel space. 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 (the
>>> list is incomplete and I don't really know if all of them are yet
>>> implemenent in userspace) in my opinion. That would make them easier to
>>> maintain (changes in the kernel would only affect fuse, once fixed all
>>> the userspace filesystem would work again).
>>>
>>>     As a bonus, we would get many working fs based on fuse. In the
>>> server side gluster is a desirable thing; in the desktop things like
>>> gvfs (in the linux world gvfs is used not only by gnome but also by kde
>>> or xfce) or truecrypt
>>
>> I'm really concerned also about ntfs and smbfs at the moment. It seems
>> that there is also a FUSE smbfs port, but I never used it and I'm not
>> sure about its state at all.
>
> From what I understand, Apple have done a considerable amount of work
> on the FreeBSD-drived smbfs in the latest versions of OS X, based on
> the existing smbfs in tree:

I've also found that there are 2 FUSE modules for smbfs but pho_at_ and
flo_at_ still haven't tested them. It may make sense to do so before we
commit FUSE to -CURRENT. However, thee is a plan by a $COMPANY to work
on the in-kernel version of smbfs and lock it before 10.0 is shipped.
In the unlikely events this doesn't happen we will came up with a
different plan (assuming we will adopt anyway the FUSE module, if it
proves to work well).

>     http://www.opensource.apple.com/source/smb/smb-552.5/
>
> I imagine things like the filesystem locking are probably somewhat
> different, but in terms of updating smbfs itself to support newer
> features it may be a good base (licensing permitting). smbfs at the
> moment lacks in some areas such as DFS support, although I do not know
> if the OS X version is any different there (given the consumer focus
> of their OS, probably not). There was also a version spun off by
> OpenSolaris:
>
>     http://hub.opensolaris.org/bin/view/Project+smbfs/
>
> which again was based on the FreeBSD + Apple versions.
>
> I also have a vested interest in NWFS continuing to work - only from a
> legacy point of view where we still interoperate with a number of
> Netware 6 servers through this. While those will likely eventually go
> away, more than likely before we move to 10.x, if there is anyone
> capable of working on it we could supply a test environment.
> Unfortunately the actual locking of the NWFS and NCP modules is
> outside my sphere of knowledge...

If you have NCP, do you think you can try this netncp I never
committed because lack of testing?:
http://lists.freebsd.org/pipermail/freebsd-fs/2009-January/005617.html

IIRC, Apple does a similar thing for netsmb (which suffers from a
similar problem as netncp).
Do you know if FUSE can support NWFS in any way?

Starting providing stress-tests on the current codebase for
NWFS/NetNCP (and report bugs found, preparing a list) could be a good
way to start the locking effort. Interested developers then can look
into such a list and provide necessary insight.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein