On Fri, Jan 5, 2024 at 4:08 PM Stefan Metzmacher <metze@xxxxxxxxx> 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
