Giving a VFS a chance to be told that an oplock break is occurring

[Richard Sharpe]

On Wed, Mar 28, 2012 at 5:13 PM, Jeremy Allison <jra at samba.org> wrote:
> On Wed, Mar 28, 2012 at 05:02:41PM -0700, Richard Sharpe wrote:
>> On 3/28/12, Jeremy Allison <jra at samba.org> wrote:
>> > On Wed, Mar 28, 2012 at 08:35:56PM +0200, Volker Lendecke wrote:
>> >> On Tue, Mar 27, 2012 at 07:51:09PM -0700, Richard Sharpe wrote:
>> >> > > Definitely widen out to samba-technical... I'm CC:ing vl on the
>> >> > > reply for his thoughts, I know he's spent more time thinking about
>> >> > > async issues in the VFS than I have.
>> >> >
>> >> > If you are doing read-ahead or write-behind in a VFS module and an
>> >> > oplock break occurs then you need to know about it, it seems to me,
>> >> > either to invalidate or flush ...
>> >>
>> >> With the current oplock architecture, isn't it possible also
>> >> messaging_register for a MSG_SMB_BREAK_REQUEST with a
>> >> different handler? This way you will get the Samba-internal
>> >> oplock breaks. You could also very cheaply compare
>> >> fsp->oplock_type with a value cached locally in your module.
>> >> If that changes, a break has happened.
>> >
>> > Oooh. Good catch - yes that's true.
>>
>> Do we get told when the break is happening or after the fact?
>>
>> After the fact is OK for read caching but not for write(-behind) caching.
>>
>> Imagine we have write(-behind) cached data. An oplock break arrives
>> and the client is told to break back to something lower than
>> exclusive, but it has no data.
>>
>> However, if the VFS is also not told then and only discoveres it later
>> when an operation arrives, then we might have lost writes ...
>
> The holder of the oplock gets the MSG_SMB_BREAK_REQUEST message
> when someone else requests an open that would break - i.e. the
> receiver of this message is the process that should do the
> break. You can register multiple handlers to receive the message
> so long as the private pointer is different for each - that
> allows multiple stacked modules to register.
>
> However you don't get to select the order in which the
> handlers are run, so if you require synchronous operation
> that might be a problem.

OK, that is great. I don't (think I) care what order they are
delivered in, just as long as they are delivered before the other
party opening the file get the go ahead to read/write the file.

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