vfs_auto

[David Disseldorp]

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

> 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).
- Some modules use extra "module: option" parameters. Would these also
  be handled by vfs_auto, or require manual configuration?
- How would we test the different permutations and combinations? Extend
  the selftest [fs_specific] tests?
- 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.

Cheers, David