Patch: Implement FSCTL_LMR_REQUEST_RESILIENCY

[Michael Adam]

On 2014-10-09 at 16:50 -0700, Jeremy Allison wrote:
> 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 !!!!!!

Er, I meant personal repos, of course, not private.
All our work on this is public, and the branches
have been communicated at several occasions, e.g.
also listed on
https://wiki.samba.org/index.php/Samba3/SMB3

> Just to make that clear :-).

If you were also referring to personal repos,
your hatred is of course your personal problem. ;-)
I think personal repos are the perfect vehicle
for working on features without flooding the
upstream repo with unfinished code prematurely.

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

Er, I'm talking about them. On the list. Ain't I?

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

No, this is humbug. We only need to make sure
code gets into master once it is ready. And
as I said before, we have been and are putting those
parts into master that were ready. Putting
WIP/POC code into master prematurely is
the wrong move. This is what personal repos
are for: letting code ripen until it is ready.

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

:) Working on it...

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

We do that already with durable handle reconnect since 4.0.

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/20141010/60ff1987/attachment.pgp>