Lease keys and hardlinked files

[Tom Talpey]

On 12/8/2023 12:01 PM, Steve French wrote:
> Following up on a question about hardlinks and caching data remotely,
> I tried a simple experiment:
> 
> 1) ln /mnt/hardlink1 /mnt/hardlink2
>     then
> 2) echo "some data" >> /mnt/hardlink1
>     then
> 3) echo "more stuff" >> /mnt/hardlink2
> 
> I see the second open (ie the one to hardlink2) fail with
> STATUS_INVALID_PARAMETER, presumably due to the lease key being reused
> for the second open (for hardlink2) came from the first open (of

Ok, so that is a client bug.

> hardlink1).  It would be logical that leasekeys depend on the inode
> not that the pathname (so could handle hardlinks on the same mount)
> but that appears not to be the case.

Logical, maybe, but the client's inode is not any business of the
server's.

> Interestingly the case when two clients access the hardlink (or eg.
> nosharesock mount to same share on /mnt1 and /mnt2) works more
> logically:
> 
> 1) hardlink /mnt1/hardlink1 /mnt1/hardlink2
>     then
> 2) nosharesock mount /mnt2 to the same share
>     then
> 3) echo "some data" >> /mnt1/hardlink1
>     then
> 4) echo "more data" >> /mnt2/hardlink2
> 
> What you see at step 4 is the open of /mnt2/hardlink2 generates a
> lease break of the (deferred close) handle on /mnt1/hardlink1 from RWH
> to RH, and the open of /mnt2/hardlink2 is given RH then after the
> write to hardlink2 you see a lease break from RH to none as expected
> before the close.

That's expected, by design in the protocol. The issue Shyam and
Meetakshi were attempting to address is that the lease break can
cause a storm of dirty page pushes, and crediting gets in the way.

Which may well be a second client bug.

Tom.