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