On Sun, Sep 12, 2010 at 9:55 AM, Pavel Shilovsky <piastryyy@xxxxxxxxx> wrote: > 2010/9/12 Jeff Layton <jlayton@xxxxxxxxx>: >> 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. We already downgrade olocks. I don't think we have seen problems with the downgrade from "cache everything" to "cache only reads" - I don't think the client "response" to the oplock downgrade has to set additional flags in the "response" to the oplock break. >> I'll concede though that the spec is nebulous here. It might be >> worthwhile to make a dochelp request to MS on this point. -- Thanks, Steve -- 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
