chungen0126 commented on PR #10764:
URL: https://github.com/apache/ozone/pull/10764#issuecomment-5284213971
> The read starts at block offset 2048, but chunk3 starts at 1034, so 2048
is internal offset 2048 - 1034 = 1014 inside chunk3 — not a checksum-window
boundary (1014 % 1024 != 0). chk3-1 is the checksum of chunk3's first window,
covering block bytes [1034, 2058), whereas the returned data begins at 2048. So
checksums.get(0) does not match the first bytes of the read.
>
> The test passes only because the chunks carry placeholder labels
("chk3-1") instead of real CRCs over real bytes, so nothing ties the checksum
to the data.
> This assumes the read offset lands on a chunk's internal checksum
boundary, but reads are only aligned to the global bytesPerChecksum grid. Once
a short chunk shifts later chunks off that grid, a partial read starting inside
a chunk selects/computes checksums over the wrong byte range and throws a false
mismatch
Thanks for pointing this out. The core issue is that the initial
`blockOffset` was not converted to its relative offset within the containing
chunk before computing the checksum alignment.
Since each chunk maintains its own checksum grid starting from its byte 0,
the read alignment only needs to be adjusted for the starting offset relative
to that chunk. Once the start offset is correctly aligned, the subsequent chunk
processing and iteration logic remain valid. I will update the initial offset
calculation accordingly.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
