Re: CIFS data coherency problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2010/9/12 Jeff Layton <jlayton@xxxxxxxxx>:
>> We can write a data in write_end call all the time when we don't have
>> an oplock for writing. If we get an error we simply returned it in
>> from write_end and an application gets it.
>>
>
> I don't understand the above statement. Can you clarify it?

Yesterday, I sent the patch to the list, that clarifies my idea. I
mean we use do_file_aio_write instead of cifs_file_aio_write call but
in cifs_write_end call (that should actually write data to the
storage) we check for an oplock. If we have the Exclusive oplock for
this file id, we don't write to the server and mark page as dirty. In
other cases we write to the server in cifs_write_end call. You can
find the code that does it in my patch.

> That's just because our client is primitive in this regard. When an
> oplock break comes in, it always drops the entire oplock rather than
> trying to downgrade it.
>
> Notice that when the client sends the "reply" that it's actually a
> request. The client never sends an actual "response" to an oplock
> break. What it does is send a new LOCKING_ANDX request to the server
> with a Lock Type of oplock break (0x02) and an oplock level of 0.
>
> My interpretation has always been that this "response" from the client
> tells the server what new oplock level the client has elected to take.
> In this case, it elected to drop the lock altogether so the server has
> no need to send a new oplock break.
>

You can find the code (misc.c, is_valid_oplock_break call) that
downgrades the oplock for the client according to the field
NewOplockLevel in Oplock Break sent by the server. But then you can
see that in cifs_oplock_break call (file.c) the client simply sends
acknowledge without setting any OplockLevel specific things.

> I'll concede though that the spec is nebulous here. It might be
> worthwhile to make a dochelp request to MS on this point.
>

I agree - without special point in spec it's the open question.

-- 
Best regards,
Pavel Shilovsky.
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux