Patch: Implement FSCTL_LMR_REQUEST_RESILIENCY

[Richard Sharpe]

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.

>> 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.

> 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.

HyperV adds an Extra Create Parameter/Context that is tagged with a
GUID (blob, not string) that handles the SVHDX_OPEN_DEVICE_CONTEXT as
specified in MS-RSVD. There are some things specified there that
actually need to be implemented. I have created a patch for Wireshark
(which is now in the Wireshark master branch) to dissect these things
and am slowly working on some changes in Samba master to handle blobs
as tags for Extra Create Contexts/Parameters.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)