On Fri, Feb 14, 2025 at 01:13:52AM +0100, Christoph Anton Mitterer wrote: > On Wed, 2025-02-12 at 08:50 +0100, Salvatore Bonaccorso wrote: > > Yes my undsetstanding from your comments was that 6.12.13-1 does not > > expose the problem. > > Okay... let me summarise :-) > > - 6.12. doesn't show the original problem (hanging mv) described in > this bug > I briefly (and wrongly) thought, that instead the NFS4.1 mountpoint > would not update the file size after the mv succeeded, but that was > probably just a mistake on my side. > - The bookworm kernel *does* show the original problem (hanging mv).
Then after all my marking as fixed in 6.12.13-1 was actually okay, and the BTS knows that the 6.1.y version was still unfixed. > > I have reopened the bug, but I believe the only one who actually can > > do something here is either you, and bisect the changes down to what > > broke the behaviour, or someone else using dCache and having the > > possiblity to do experiments on a dedicated note. > > > > I would start bisecting first by debian kernel-image packages by > > narring down more closely where the behaviour got introduced, then > > from there the respective upstream stable series changes. > > > > I hope this gives you enough guide already on how to proceed. > > Hmm I guess that would rather be rather be quite a "waste" of time. > I cannot really test this on our production system, so I'd need to set > up a test system for bisecting. > And I have anyway adapted my use cases of this already with a TODO to > revert after upgrading to trixie. > > My only idea was that we might just leave it open in case someone else > stumbles over the symptom. > > But perhaps it's indeed best to just close it as wontfix. > > Sorry for the back and forth :-) No problem, but given that yes I will close it with the known version fixing the problem and then let the bug go :) Regards, Salvatore
