Hello dochelp! Here comes another Persistent Handle related question... :)
While initially testing and implementing Persistent Handle with various leases levels, just today I also drilled into Windows server behaviour when contending Persistent Handle with various oplock levels.
It seems with when using oplocks, the Persistent Handle is not sufficiently protected against contending opens.
I see the following expected behaviour when using leases: 1. Client 1: open file with lease=RWH, sharemode=RW 2. Client 1: TCP disconnect3. Client 2: open file with RW access -> STATUS_PENDING, the open gets deferred until step 8 below
4. Client 1: reconnect TCP and SMB 5. Client 1: reconnect open 6. Server to client 1: lease break from RWH to RH 7. Client 1: lease break ack 8. Server to client 2: open succeedsIow, the contending open is defferred as long as the PH is disconnected and the lease break is not acked.
Not so much with oplocks: 1. Client 1: open file with a batch oplock, sharemode=RW 2. Client 1: TCP disconnect3. Client 2: open file with RW access -> STATUS_PENDING, the open is briefly deferred, but then succeeds in step 4:
4. Server to client 2: open succeeds 5. Client 1: reconnect TCP and SMB6. Client 1: reconnect open, batch oplock was downgraded to a level-ii oplock
Is this expected behaviour? As afaict Persistent Handles are not really covered my MS-FSA, I'm using the SDC presentation "SMB 2.2 : Bigger, Faster, Scalier" from 2011 as guidance which states
Exclusive (W) leases are preserved via blocking new creates from other clients. on page 47. It doesn't explicitly mention oplocks though... I can share network traces of both scenarios. Thanks! -slow
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
