public inbox for goredo-devel@lists.stargrave.org
Atom feed
From: "Niklas Böhm" <mail@jnboehm•com>
To: goredo-devel@lists.cypherpunks.su
Subject: Question/confusion about "size differs" for ood detection
Date: Wed, 8 Jan 2025 21:55:12 +0100	[thread overview]
Message-ID: <b144d1ae-02fc-482c-b66a-cdb672f7b9d4@jnboehm.com> (raw)

Hello,

I ran into some weird behavior that I cannot quite make sense of.  I 
have a target which went ood and I redid it.  But to my surprise, 
targets depending on this one downstream reported that they are ood, the 
reason is that the size differs.  But when I go to check it manually, 
the size reported in the .dep file matches with what the file system 
gives me, the hash also matches (which does not matter for this concrete 
use case).

I found out that calling redo-depfix will somehow fix this mismatch and 
make it go away.  But I don't quite understand the reason for why this 
showed up in the first place.

What I thought could be a reason is that I may have interrupted the 
downstream target while doing this, which I suppose could lead to an 
incomplete write to the .dep file.  But I somehow think that is unlikely 
and would also not explain why redo-depfix can then recover from this 
situation.  (I also tried to reproduce this with a toy example, but was 
not able to do so.)

Basically, the reason the "size differs" ood was triggered is because 
the first 8 bytes of the inode struct differ, because the following 
evaluates to true:

	!bytes.Equal(inode[:8], ifchange.Inode()[:8])

I don't understand why this would be the case, if the .dep file reports 
the correct size.  The file in question is only 122MB large, so that 
shouldn't trigger any issues.  Likewise, being on a little endian 
architecture also shouldn't matter (I saw that the bytes are written as 
big endian).  This whole situation left me a bit stymied.

In any case, I was wondering if there is a straightforward explanation 
for this behavior.  Or is there something unexpected happening?

Best
Nik

PS: thanks for the randomized sleeping.  I agree that this does not 
require a release by itself.

             reply	other threads:[~2025-01-08 21:21 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-08 20:55 Niklas Böhm [this message]
2025-01-09 12:13 ` Question/confusion about "size differs" for ood detection Sergey Matveev