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

[Richard Sharpe]

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

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