Hey Salvatore
On Fri, 2025-02-07 at 14:25 +0100, Salvatore Bonaccorso wrote:
> Sure, but it is still a very specialized usecase. As I understand
> there is for instance the PoolManager which takes action when a user
> performs a reading or writing operation on a file.
Yes. Though I would not expect the PoolManager to take part in this, as
it's just a rename in the virtual filesystem provided by dCache
("Chimera").
Only the PnfsManager (which is the interface to that) should be queried
here.
Also, the deletion of the old destination file that got unlinked by the
rename, doesn't happen immediately in dCache but is only scheduled to
happen (and this again should happen without PoolManager).
The smoking gun, why this may rather be a kernel issue is:
a) it worked in older kernels
b) it works[0] (again) in current sid kernels
> And I noticed you
> filled earlier a (maybe related)
> https://github.com/dCache/dcache/issues/6592
Yeah,... it was actually about the issue and back then I hoped to get
some feedback.
But still, given that it works again (i.e. no hang) with 6.12.13 (and
when I tested during my original report, I had 6.4.x)... I'd rather say
that it sounds like a regression introduced somewhere after 5.10.179-3
but at least in 6.1.x.
> I still supect that the dCache develpers might need to help here to
> see if they can reproduce in lab conditions to narrow down the
> problem.
I'll report the [0] bug in a few minutes, maybe that triggers some more
feedback, but not sure.
Also, with trixie looming ahead,... don't put too much effort into
this.
Maybe just keep it open in case someone stumbles over the same issue.
Cheers,
Chris.
[0] Well there is another bug showing up (this time most likely being
actually a dCache bug, i.e. the "new" file (after the move) shows the
size of the old one, while it actually has the content of the new.
Probably a caching issue in dCache's NFS door.
