abartlet at samba.org
Tue Jun 24 04:59:27 MDT 2014
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
> - 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
> - 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 http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
More information about the samba-technical