Patch: Implement FSCTL_LMR_REQUEST_RESILIENCY

[Jeremy Allison]

On Thu, Oct 09, 2014 at 11:35:24PM +0200, Michael Adam wrote:
> On 2014-10-09 at 14:24 -0700, Jeremy Allison wrote:
> > On Thu, Oct 09, 2014 at 11:18:47PM +0200, Michael Adam wrote:
> > > 
> > > In the new mode the process and the file handle simply does not
> > > go away if the client is disconnected. The reconncted client's
> > > tcp socket is passed to the smbd that still holds the file open.
> > > 
> > > > IMHO in our current architecture closing and
> > > > re-opening would be a much easier first step.
> > > 
> > > Sure, bug my point was rather that we might benefit from
> > > the infrastructure that we are currently building anyways
> > > for Multi-Channel.
> > 
> > Sounds good to me. We're close to getting this
> > working (once I've gotten Volker's leases code
> > in 4.2.x I'll start working on it :-).
> 
> This part is already largely working, btw.
> (See the master-multi-channel(-*) branches that
> Metze and I ar ping-ponging in our private repos.)

I HATE PRIVATE REPOS !!!!!!

Just to make that clear :-).

Unless you talk about them on the list,
no one knows they exist, and no one knows
what is being done there.

They might as well be vaporware :-).

> I have a demo of multi-channel working, all
> channels treated by one smbd. I presented it
> in Redmond. I still need to record a desktop
> session with that.

Actually, you need to make sure everything
is in master, so others can play with it
(sorry if it already is, been working on
other stuff at the moment :-).

> The tcp-session passing based on the GUID
> is probably something that we might consider
> polishing and pushing next in the process
> of implementing multi channel. Fd-passing as

Can't happen soon enough for me :-).

> such is already upstream and so is the preparation
> of the smbXsrv structures to handle multiple
> transport connection in one process.


> Right. And in principle the disconnected handle needs
> to survive a restart of samba or a reboot of the server,
> especially if it is a node in a cluster. At least for
> persistent handles (if not for resilient ones).
> And hence we also need to treat the case of a closed fd
> anyways. Then we can as well start out with this.
> For this we have the challenge of making the corresponding
> database records persistent without killing performance
> by making the whole database persistent.
> This seems to be the harder part.

We can work up to this slowly I think.
We certainly need to be able to cope
with a closed fd being reopened.