Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #85484 > unrolled thread

Bug#1049873: closing 1049873

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1049873: closing 1049873 Christoph Anton Mitterer <calestyo@scientia.org> - 2025-02-11 23:00 +0100
    Bug#1049873: closing 1049873 Salvatore Bonaccorso <carnil@debian.org> - 2025-02-12 09:00 +0100
      Bug#1049873: closing 1049873 Christoph Anton Mitterer <calestyo@scientia.org> - 2025-02-14 01:20 +0100
        Bug#1049873: closing 1049873 Salvatore Bonaccorso <carnil@debian.org> - 2025-02-14 06:50 +0100

#85484 — Bug#1049873: closing 1049873

Hey.

I think you misunderstood me:

Only the part where I thought that dCache showed the old size (after
the move has happened, without hanging, when using a current kernel) is
a non-issue.

The problem in 6.1.x, that mv hangs *is* still happening.

Cheers,
Chris.

[toc] | [next] | [standalone]

#85487

Hi,

On Tue, Feb 11, 2025 at 10:52:21PM +0100, Christoph Anton Mitterer wrote:
> Hey.
> 
> I think you misunderstood me:
> 
> Only the part where I thought that dCache showed the old size (after
> the move has happened, without hanging, when using a current kernel) is
> a non-issue.
> 
> The problem in 6.1.x, that mv hangs *is* still happening.

Yes my undsetstanding from your comments was that 6.12.13-1 does not
expose the problem. 

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.

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#85502

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).


> 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 :-)


Cheers,
Chris.

[toc] | [prev] | [next] | [standalone]

#85503

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web