[PATCH 2/2] smb: client: retry compound request without reusing lease
Shyam Prasad N
nspmangalore at gmail.com
Fri Jan 5 10:58:14 UTC 2024
On Fri, Jan 5, 2024 at 4:08 PM Stefan Metzmacher <metze at samba.org> wrote:
>
> Hi Shyam,
>
> >> Maybe choosing und using a new leasekey would be the
> >> way to start with and when a hardlink is detected
> >> the open on the hardlink is closed again and retried
> >> with the former lease key, which would also upgrade it again.
> >
> > That would not work today, as the former lease key would be associated
> > with the other hardlink. And would result in the server returning
> > STATUS_INVALID_PARAMETER.
>
> And that's the original problem you try to solve, correct?
Correct. I thought you were proposing this as a solution.
>
> Then there's nothing we can do expect for using a dentry pased
> lease key and live with the fact that they don't allow write caching
> anymore. The RH state should still be granted to both lease keys...
Yes. It's not ideal. But I guess we need to live with it.
Thanks for the inputs.
Steve/Paulo/Tom: What do you feel about fixing this in two phases?
First, take Meetakshi's earlier patch, which would fix the problem of
unnecessary lease breaks (and possible deadlock situation with the
server) due to unlink/rename/setfilesize for files that do not have
multiple hard links. i
.e. during these operations, check if link count for the file is 1.
Only if that is the case, send the lease key for the file. This would
mean that the problem remains for files that have multiple hard links.
But at least the hard link xfstest would pass.
As a following patch, work on the full fix. i.e. maintain a list of
lease keys for the file, keyed by the dentry.
This patch would replace the cinode->lease_key with a map/list, lookup
the correct lease from the list on usage.
This would obviously remove the check for the link count done by the
above patch.
Reason being that we already have the first patch, and I'm not sure
we'll be able to work on the second one soon enough.
>
> metze
>
--
Regards,
Shyam
More information about the samba-technical
mailing list