On Sat, 11 Sep 2010 11:08:15 +0400
Pavel Shilovsky <piastryyy@xxxxxxxxx> wrote:
> 2010/9/11 Jeff Layton <jlayton@xxxxxxxxx>:
> > So what? Why should the writer know anything about whether it succeeds
> > before a flush or close occurs? POSIX does not mandate that. If you are
> > able to report an error at write time, then that's fine. It's not
> > required however.
>
> 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?
> > That's not how I read this:
> >
> > 57: server downgrades oplock on 0x0001 to level 2
> > 60: client drops oplock altogether for 0x0001 (note that it replies
> > with oplock level 0)
> > 65: server revokes oplock on 0x0002 altogether
> > 66: client "acks" the oplock break
> >
> > At that point there are no more oplocks held. Why would the server need
> > to send another oplock break?
>
> It (60) is the Oplock Break acknowledge request that's sent by the
> client on the server's Oplock Break Notification (57). According to
> the spec (page 214, section 2.2.4.32.1 of [MS-CIFS].pdf)
> NewOpLockLevel field is used by the server to indicate new oplock
> level for the FID. There no words that says that this field is used by
> the client in acknowledge. An acknowledge is only used to indicate
> that all the dirty data and byte-range locks are flushed to the server
> and doesn't bring any other information. It's my understanding of the
> spec.
>
> Even more, CIFS client does it according to the spec (file.c, line 2341):
>
> if (!cfile->closePend && !cfile->oplock_break_cancelled) {
> rc = CIFSSMBLock(0, cifs_sb->tcon, cfile->netfid, 0, 0, 0, 0,
>
> LOCKING_ANDX_OPLOCK_RELEASE, false);
> cFYI(1, "Oplock release rc = %d", rc);
> }
>
> and there is no mention of OplockLevel in CIFSSMBLock call.
>
> So, as you can see above: there is no value that is set to OplockLevel
> field of SMB_COM_LOCKING_ANDX command.
>
> That's why I said that client1 continues keeping the level II oplock.
>
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.
I'll concede though that the spec is nebulous here. It might be
worthwhile to make a dochelp request to MS on this point.
--
Jeff Layton <jlayton@xxxxxxxxx>
--
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
