Best practices: Adding Persistent Handle support

[Stefan Metzmacher]

Hi Chris,

> I'm working on Persistent (and Durable) handles.  For Persistent handles, I
> need to enable a connection-level capability plus a share-level capability.
> 
> It seems (to me) that I should add a per-share configuration variable that
> indicates that the specified share supports Continuous Availability (CA;
> Persistent Handles).
> 
> My other thought, however, is this:
> - I am implementing CA using a VFS module.  I believe that this is a valid
>   approach, because it allows us to adapt to whatever underlying mechanism
>   the file system might support on its own.
> - We can also write a "generic" Persistent Handle VFS module that works
>   with whatever mechanism Martin and Amitay develop.

The core smbd engine needs to have support for persistent handles first.

There're 3 layers:
- the top level one:
  That has all the mappings from wire to the internal state
  see smbXsrv_open and smbXsrv_open_global0. I guess these
  will always be maintained by the core smbd logic, so
  we need a way to distribute these persistent to all nodes
  in a cluster or across smbd restarts on a non-clustered server.

- a glue layer:
  This maintains the locking.tdb, brlock.tdb, lease_db.tdb,
  in theory this can be moved behind the vfs layer, but
  it would require a lot of work. So the core smbd layer
  need to keep them persistent.

- the filesystem layer:
  This maintains the file descriptor (from the kernel or a userspace
  filesystem) and the kernel oplocks, kernel share modes and posix
  locks. This is hidden behind the VFS and the VFS module
  needs to keep them persistent.

> That's my thinking, but it leads to another idea.  The Persistent Handle VFS
> module would need to be loaded on a per-share bases, since not all shares
> would have CA capabilities.  So, shouldn't loading the module, by itself,
> trigger both SMB2_SHARE_CAP_CONTINUOUS_AVAILABILITY on the share and
> SMB2_GLOBAL_CAP_PERSISTENT_HANDLES for the server as a whole.  I imagine
> that there would need to be a call in vfs_<whatevver>_init() function that
> would tell smbd to send SMB2_GLOBAL_CAP_PERSISTENT_HANDLES if SMB3+ is
> negotiated.

Once the core smbd logic supports persistent handles, we can always
announce SMB2_GLOBAL_CAP_PERSISTENT_HANDLES on the connection.

Then it's easy to control SMB2_SHARE_CAP_CONTINUOUS_AVAILABILITY based
on the used vfs module.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170602/7b0a2c24/signature.sig>