On Thu, 2019-03-07 at 12:03 +0100, Stefan Metzmacher via samba- technical wrote: > Am 06.03.19 um 22:25 schrieb Ralph Böhme via samba-technical: > > Jeremy Allison wrote: > > > On Wed, Mar 06, 2019 at 03:31:08PM -0500, Jeff Layton wrote: > > > > On Wed, 2019-03-06 at 10:11 -0500, J. Bruce Fields wrote: > > > > > Jeff, wasn't there some work (on Ceph maybe?) on a userspace delegation > > > > > API? Is that close to what's needed? > > > > > > > > > > > > > Here's the C headers for that stuff: > > > > > > > > https://github.com/ceph/ceph/blob/7ba6bece4187eda5d05a9b84211fe6ba8dd287bd/src/include/cephfs/libcephfs.h#L1734 > > > > > > > > It's simple enough and works for us in ganesha, and I think we can > > > > probably adapt it to samba without too much difficulty. The callback > > > > doesn't seem like it'll do for a kernel API though -- you'd almost > > > > certainly need to do something different there (signals? inotify?). > > > > > > SMB3 leases have R/RW and Handle-based leases. > > > > Just to be precise: SMB2.1+ has R, RH, RW and RWH leases. > > > > > Handle leases allow multiple opens of the same pathname > > > that get different handles to share the lease, allowing > > > a client redirector to delay opens or closes locally > > > so long as it has a handle lease. > > > > That'a a propertly of leases in general, not just H-leases. The client provides a lease key which is a GUID with each lease request > > > > > Here are the semantics: > > > > > > https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/d8df943d-6ad7-4b30-9f58-96ae90fc6204 > > > > > > I'm not sure a simple file-descriptor based API is > > > enough for us. Can he have a uuid or token based > > > API instead where the server can chose what fd's > > > to cover with a token ? > > > > Yes, that would be ideal. > > If we want to design an useful API, we also need to think about > all features: > - file oplock/leases > - directory leases > - share modes > - disconnected handles (for durable and persistent handles), > which exists within the kernel for a while and can be reattached > to process, using some kind of cookie and the same euid > - the API needs ways to use epoll in order to do async opens > and lease breaks. For opens the model of async socket connects > could be used. Leases could have a signalfd-style api. > > We may not need everything at once, but we should have the full picture > in mind. And we need working code in kernel and userspace that passes > all tests (we may need to add additional test). Otherwise the kernel > creates new syscalls, which wouldn't be used by Samba in the end. Just a thought, but you should probably classify these facilities in two lists, one for items that can only reasonably be done via a kernel API and one for items that can be satisfactorily be handled via a coordinating userspace component (daemon/database/convention/other). Getting all that stuff in kernel may prove overly hard and contentious so being able to negotiate on the critical items only may be important. Simo.
