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.
