vfs_auto

[Andrew Bartlett]

On Tue, 2014-06-24 at 12:34 +0200, David Disseldorp wrote:
> Hi Andrew,
> 
> On Tue, 24 Jun 2014 19:07:26 +1200, Andrew Bartlett wrote:
> 
> > G'Day,
> > 
> > Seeing what looks like a really interesting module in vfs_snap, and
> > thinking about the trouble folks running btrfs and zfs have with Samba,
> > having to run specific modules, I wondered if we should have a new,
> > meta-module: vfs_auto
> > 
> > That is:  We can detect almost as well as the system administrator what
> > VFS modules they need for specific back-end file systems, and we hide so
> > much of our correctness code behind optional, off by default modules.
> > 
> > This is all OK if our users are NAS vendors and others who control the
> > end environment, and so know to turn on modules, but what about everyone
> > else?  Why shouldn't Samba 'just work' with a bare minimum of
> > configuration?  Why should good features like streams support, snapshot
> > creation, copy_chunk or full NT ACLs be hidden inside otherwise unknown
> > modules?
> 
> Copy-chunk is supported by default. Btrfs specific COW copy-chunk is
> separate - see https://wiki.samba.org/index.php/Server-Side_Copy

OK.  Is there any reason not to enable this where available?

> > We do this already for POSIX ACLs, with vfs_default calling into the
> > 'right' ACL code as detected at build time, but could we do this in
> > general, including for other features?
> > 
> > We also do this already for LDB, with samba_dsdb being the meta-module
> > loading the correct other modules. 
> > 
> > It would also allow us to handle better what is done in loadparm for the
> > AD DC, as the default VFS modules could vary based on server role. 
> > 
> > We could handle the upgrade problem by leaving the default to be "", but
> > to encourage folks to set it to "auto" in documentation and examples.
> > Folks that want strict control and no changes could still specify an
> > exact set of modules.
> > 
> > What do others think?  Does someone want to have a go at implementing
> > this?
> 
> In general I don't find this a bad idea, but I'm still left with a few
> concerns:
> - How does an administrator know which modules have been enabled?
> 	- This could easily lead to confusion, and double or conflicting
> 	  definitions (e.g. bso#10560).

It was this bug I was hoping this might address - that is on an AD DC
using btrfs, that both would be enabled automatically.  Certainly I
agree we would have to indicate somewhere what 'auto' meant in a
particular situation. 

> - Some modules use extra "module: option" parameters. Would these also
>   be handled by vfs_auto, or require manual configuration?

Ideally the defaults would be selected so as to be useful on their own.

> - How would we test the different permutations and combinations? Extend
>   the selftest [fs_specific] tests?

I think that is a reasonable approach.

> - If module functionality is considered stable and mainstream enough
>   that it should be enabled automatically, why not put it in the default
>   code-path, with relevant build/runtime checks.

I guess what I'm suggesting is that like in the dsdb modules of the AD
DC, code may be written in terms of a module, but used by default.  That
way it is still in an easily identified and understood chunk.

Andrew Bartlett

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba