Patch: Implement FSCTL_LMR_REQUEST_RESILIENCY

[Michael Adam]

On 2014-10-08 at 08:21 -0700, Richard Sharpe wrote:
> On Wed, Oct 8, 2014 at 8:02 AM, Michael Adam <obnox at samba.org> wrote:
> > Hi Richard,
> >
> > On 2014-10-08 at 07:29 -0700, Richard Sharpe wrote:
> >> Hi folks,
> >>
> >> There are indications that HyperV requires the server to implement
> >> FSCTL_LMR_REQUEST_RESILIENCY, so I have a proposed implementation of
> >> it.
> >
> > I expect that persistent handles will also be sufficient.
> 
> It's not. I have a capture against master where a resilient handle is
> requested and responded to, but HyperV fails when it tries to request
> a change in the resiliency period.

Sure. My point is was that Hyper-V would not be requesting
reslient handles if it could even get persistent ones.
Against Samba, the hyper-v requests resiliency because it
could not get a persistent handle.
(Following the advice of engineers of MS, persistent handles
kind of supersede resilient ones. They are superior since
they are transparent to the application and treated by the
redirector.)

> >> Attached is a patch for both FSCTL_LMR_REQUEST_RESILIENCY and a small
> >> torture test for it (doesn't do much as yet.)
> >
> > Your patch implements the mere protocol head of
> > resiliency, but it ignores the actual difficulty:
> >
> > While "durable handles" is a best effort concept,
> > resilient (and persistent) handles are not. They
> > have certain guarantees attached to them as soon
> > as they have been handed out by the server. The
> > fundamental challeng is more or less the same
> > for persistent and resililent handles, only the
> > exact characteristics are different.
> >
> > Basically the server guarantees that it will
> > (in contrast to the case of durable handles)
> > prevent other clients/processes from accessing
> > the opened file for a certain period of time
> > when the client is disconnected. With durable
> > handles, the disconnected handle is closed
> > when another process tries to access it.
> >
> > This is why we haven't implemented resilient handles yet.
> > We simply can't claim to implement it if we can't
> > provide the guarantees.
> >
> > Also, our current implementation does not keep
> > the underlying unix file open while the smb client
> > is disconnected. Instead it stores the state in
> > the database and reopens the file, and re-establishes
> > the state when a durable reconnect is done.
> 
> OK, so there is more work to do. Why do we need to keep the file open
> at the UNIX level? Surely it is the same to open it again when the
> client sends a D2NC or whatever.

We don't strictly need to keep the unix file open
(as proven by the implementation of durables),
but this would make several things easier.
In particular, only this way we would have a chance
to notice when a non-samba-process tries to access
the file.

> > A first step towards implementing resililency might be to keep
> > the file open when the client is disconnected. This was not
> > easily possible with the existing infrastructure of
> > one process per TCP connection (a reconnecting client
> > ends up in a different process).
> >
> > But with the WIP work on multi-channel, we can now
> > keep an smbd running when clients are disconnected,
> > and we could hence easily implement keeping open
> > the unix file of a disconnected handles. When the
> > client reconnects, the WIP code passes the connection
> > over to the existing smbd based in ClientGUID.
> > Hence here are chances implement an improved durable/resilient
> > reconnect like this. But there is still work to do
> > to ensure the guarantees.
> >
> >> Eventually, we will also have to deal with the GUID-tagged blob that
> >> is an Extra Info (Extra Create Parameter) that was in the CREATE
> >> request that precedes the FSCTL as well, I imagine.
> >
> > Which create context are you referring to?
> 
> Clearly, you haven't been following  along.

Well... I am aware that you wrote about some non-text create blob
in another mail thread, and I guessed there was a connection.
But in this mail thread, this was at least not explicit. ;-)

Cheers - Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20141008/10faf4ee/attachment.pgp>