Some deficiencies with the Samba VFS that I think need to e rectified ...

Richard Sharpe realrichardsharpe at gmail.com
Tue Dec 10 11:39:21 MST 2013


On Tue, Dec 10, 2013 at 9:03 AM, Jeremy Allison <jra at samba.org> wrote:
> On Tue, Dec 10, 2013 at 08:09:08AM -0800, Richard Sharpe wrote:
>> Hi folks,
>>
>> I have written before about wanting all VFS functions to return NT
>> Status codes and the fact that the dir related functions do not
>> provide something like an FSP, however, one more deficiency has become
>> apparent as we get more into distributed systems at my place of
>> employment.
>>
>> That is, we do not have sufficient information to make correct
>> decisions during some metadata operations. Specifically, when mkdir
>> and open are called, we really need access to fields like access_mask
>> and share_mode ...
>>
>> I wonder if it would be appropriate, early on in CreateFile, to create
>> the FSP and pre-load it with these values so we can pass along an FSP
>> to all operations that are not path-based?
>
> Well the real problem is our VFS started out as
> a simple POSIX one, which is why it became so
> popular as it's so easy to add functions, then
> it expanded into a hybrid POSIX+Windows one
> as people (like you :-) wanted to do more
> than the simple POSIX layer offered.
>
> So IMHO the question is should we leave
> the POSIX layer as-is, for people who
> want to write simple interposing VFS
> modules, but expand out (and maybe
> separate) a Windows VFS layer that
> does the extra things you need.
>
> I don't think it's a good idea to
> add Windows features to mkdir/open
> etc. Arguably if you want to do all
> these things you should be writing
> your own CreateFile layer (Isilon
> ended up going down this path).
>
> The reason this is hard is a generic
> CreateFile Windows layer has to talk
> to all the oplock/lease/share-mode
> code that's called in the rest of
> smbd, so it's not to clean to
> separate out.
>
> Maybe we should have a "VFS design
> meeting" so we can hammer out the
> requirements for a next-gen VFS
> interface.
>
> Let's keep it clean and simple though -
> no "Boil the ocean" rewrites welcome :-).

I agree pretty much with these needs. However, one of the things that
is motivating my grumbling is that we are making too many changes to
Samba, which makes life difficult for us down the road.

While writing our own CreateFile layer might be the correct approach
at some point, it means we have to write loads of functionality that
is already in Samba, which I would rather not do.

With respect to a simple Posix layer, we can still retain that even
with FSPs passed top more functions and with all functions returning
NT Status codes by providing good documentation and a simple example,
because:

1. Writers are free to ignore FSPs when they don't care about them, and

2. They can simply call map_nt_error_from_unix as the last thing done
in any POSIX functions.

However, I do like the idea of a VFS Design meeting. We need to ensure
that the correct folks are included.

-- 
Regards,
Richard Sharpe
(何以解憂?唯有杜康。--曹操)


More information about the samba-technical mailing list