On 1/3/2024 9:37 AM, Paulo Alcantara wrote:
Meetakshi Setiya <meetakshisetiyaoss@xxxxxxxxx> writes:
As per the discussion with Tom on the previous version of the changes, I
conferred with Shyam and Steve about possible workarounds and this seemed like a
choice which did the job without much perf drawbacks and code changes. One
highlighted difference between the two could be that in the previous
version, lease
would not be reused for any file with hardlinks at all, even though the inode
may hold the correct lease for that particular file. The current changes
would take care of this by sending the lease at least once, irrespective of the
number of hardlinks.
Thanks for the explanation. However, the code change size is no excuse
for providing workarounds rather than the actual fix.
I have to agree. And it really isn't much of a workaround either.
A possible way to handle such case would be keeping a list of
pathname:lease_key pairs inside the inode, so in smb2_compound_op() you
could look up the lease key by using @dentry. I'm not sure if there's a
better way to handle it as I haven't looked into it further.
A list would also allow for better handling of lease revocation.
It seems to me this approach basically discards the original lease,
putting the client's cached data at risk, no? And what happens if
EINVAL comes back again, or the connection breaks? Is this a
recoverable situation?
Also, what's up with the xfstest the robot mailed about?
Tom.
