[
https://issues.apache.org/jira/browse/HDFS-11187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17178491#comment-17178491
]
Jiang Xin edited comment on HDFS-11187 at 8/16/20, 2:27 PM:
------------------------------------------------------------
Hi [~weichiu] , thanks for your patch, but I don't think it handles all
scenario, please correct me if I misunderstood.
Consider such case: A reader thread reads a finalized replica, which have not
load the LPCC in memory, so it's LPCC is null, then it comes to
getPartialChunkChecksumForFinalized() in BlockSender#init().
{code:java}
private ChunkChecksum getPartialChunkChecksumForFinalized(
FinalizedReplica finalized) throws IOException {
...
final long replicaVisibleLength = replica.getVisibleLength();
if (replicaVisibleLength % CHUNK_SIZE != 0 &&
finalized.getLastPartialChunkChecksum() == null) {
//////
////// reader thread blocks here, and another writer thread append this
replica and succeed.
//////
// the finalized replica does not have precomputed last partial
// chunk checksum. Recompute now.
try {
finalized.loadLastPartialChunkChecksum();
return new ChunkChecksum(finalized.getVisibleLength(),
finalized.getLastPartialChunkChecksum());
} catch (FileNotFoundException e) {
...
}
{code}
At the same time, another thread append this replica and succeed. So
getPartialChunkChecksumForFinalized recompute the LPCC and set to the replica.
In this situation, the `finalized` object is old, and it's visibleLength is old
,but after loadLastPartialChunkChecksum(), it's LPCC is new, so the mismatch
happened.
I'm not sure if we need to worry about it, any advise?
was (Author: jiang xin):
Hi [~weichiu] , thanks for your patch, but I don't think it handles all
scenario, please correct me if I misunderstood.
Consider such case: A reader thread reads a finalized replica, which have not
load the LPCC in memory, so it's LPCC is null, then it comes to
getPartialChunkChecksumForFinalized() in BlockSender#init().
{code:java}
private ChunkChecksum getPartialChunkChecksumForFinalized(
FinalizedReplica finalized) throws IOException {
...
final long replicaVisibleLength = replica.getVisibleLength();
if (replicaVisibleLength % CHUNK_SIZE != 0 &&
finalized.getLastPartialChunkChecksum() == null) {
//////
////// reader thread blocks here, and another writer thread append this
replica and succeed.
//////
// the finalized replica does not have precomputed last partial
// chunk checksum. Recompute now.
try {
finalized.loadLastPartialChunkChecksum();
return new ChunkChecksum(finalized.getVisibleLength(),
finalized.getLastPartialChunkChecksum());
} catch (FileNotFoundException e) {
...
}
{code}
At the same time, another thread append this replica and succeed. So
getPartialChunkChecksumForFinalized recompute the LPCC and set to the replica.
In this situation, the `finalized` object is old, and it's visibleLength is old
,but after loadLastPartialChunkChecksum(), it's LPCC is new, so the mismatch
happened.
I'm not sure if we need to worry about it, any advise?
> Optimize disk access for last partial chunk checksum of Finalized replica
> -------------------------------------------------------------------------
>
> Key: HDFS-11187
> URL: https://issues.apache.org/jira/browse/HDFS-11187
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: datanode
> Reporter: Wei-Chiu Chuang
> Assignee: Gabor Bota
> Priority: Major
> Fix For: 3.1.0, 2.10.0, 2.9.1, 2.8.4, 2.7.6, 3.0.3
>
> Attachments: HDFS-11187-branch-2.001.patch,
> HDFS-11187-branch-2.002.patch, HDFS-11187-branch-2.003.patch,
> HDFS-11187-branch-2.004.patch, HDFS-11187-branch-2.7.001.patch,
> HDFS-11187.001.patch, HDFS-11187.002.patch, HDFS-11187.003.patch,
> HDFS-11187.004.patch, HDFS-11187.005.patch
>
>
> The patch at HDFS-11160 ensures BlockSender reads the correct version of
> metafile when there are concurrent writers.
> However, the implementation is not optimal, because it must always read the
> last partial chunk checksum from disk while holding FsDatasetImpl lock for
> every reader. It is possible to optimize this by keeping an up-to-date
> version of last partial checksum in-memory and reduce disk access.
> I am separating the optimization into a new jira, because maintaining the
> state of in-memory checksum requires a lot more work.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
