Patch: Implement FSCTL_LMR_REQUEST_RESILIENCY

[Michael Adam]

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.

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

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?

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/85fe4f8d/attachment.pgp>