[
https://issues.apache.org/jira/browse/HDDS-15886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18127582#comment-18127582
]
Chung-En Lee edited comment on HDDS-15886 at 10/15/26 6:14 PM:
---------------------------------------------------------------
[~szetszwo]
Yes, it is the first case: the hsync happens before client B opens the file.
The detail is that the data is hsync'ed in two steps within the same block:
1. client A writes 100 bytes and calls hsync
-> the last block is new, so hsyncKey updates OM: block length = 100
2. client A writes another 100 bytes and calls hsync
-> the last block is unchanged, so hsyncKey does not update OM.
The datanode has 200 bytes, but OM still records 100.
3. client B opens the file
4. client B reads the file but sees only 100 bytes
Both hsyncs complete before client B opens the file, so client B should see all
200 bytes. However, when client B opens the file, it retrieves the block length
from OM, which only records 100 bytes, so it considers the file length to be
100 bytes.
`testSyncable` hits exactly this: it writes 'a' + hflush (OM length = 1), then
'b' + hsync (same block, OM not updated), then opens a new reader. With
streamReadBlock enabled, the reader gets 'a' and then -1 instead of 'b'
(expected: 98 but was: -1).
The swapped order is not what this JIRA is about.
was (Author: chungen):
[~szetszwo]
Yes, it is the first case: the hsync happens before client B opens the file.
The detail is that the data is hsync'ed in two steps within the same block:
1. client A writes 100 bytes and calls hsync
-> the last block is new, so hsyncKey updates OM: block length = 100
2. client A writes another 100 bytes and calls hsync
-> the last block is unchanged, so hsyncKey does not update OM.
The datanode has 200 bytes, but OM still records 100.
3. client B opens the file
4. client B reads the file but sees only 100 bytes
Both hsyncs complete before client B opens the file, so client B should see all
200 bytes.
The classic read path already handles this: KeyInputStream marks the last block
of an hsync'ed file as under construction, and BlockInputStream gets the real
length from the datanode via GetBlock.
`testSyncable` hits exactly this: it writes 'a' + hflush (OM length = 1), then
'b' + hsync (same block, OM not updated), then opens a new reader. With
streamReadBlock enabled, the reader gets 'a' and then -1 instead of 'b'
(expected: 98 but was: -1).
The swapped order is not what this JIRA is about.
> Client unable to read newly synced data due to outdated block length
> --------------------------------------------------------------------
>
> Key: HDDS-15886
> URL: https://issues.apache.org/jira/browse/HDDS-15886
> Project: Apache Ozone
> Issue Type: Sub-task
> Reporter: Chung-En Lee
> Assignee: Chung-En Lee
> Priority: Critical
> Labels: pull-request-available
>
> With `ozone.client.stream.read.block` enabled, a reader that opens a file
> that is still being written can't read all the data the writer has hsync'ed.
> It hits EOF at the block length OM last recorded. With the setting disabled,
> the same read succeeds.
> Why OM's block length is out of date
> To keep OM load down, BlockOutputStreamEntryPool#hsyncKey only sends the new
> length to OM when the last block has changed. Later hsyncs that stay within
> the same block write the data to the datanodes but don't update OM. So for
> the last block of an hsync'ed file, OM's length can be shorter than what is
> actually on the datanode.
> The read path expects this. KeyInputStream marks the last block of an
> hsync'ed file as under construction (setUnderConstruction(true)).
> BlockInputStream then gets the real length from the datanode.
> StreamBlockInputStream doesn't do this. It takes blockInfo.getLength() from
> OM through BlockInputStreamFactoryImpl, stores it in a final field, and never
> checks isUnderConstruction().
> This issue was found by `TestContractCreate#testSyncable` . It fails with
> streamReadBlock enabled.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
