[
https://issues.apache.org/jira/browse/HDFS-7661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15084008#comment-15084008
]
Zhe Zhang commented on HDFS-7661:
---------------------------------
bq. 2. flush at Flush point 2.1.1, PIB1 and PIB2 were updated to PIB1` and PIB
2`, but *PIB3 failed in updating*.
After this failure, following the current error handling logic, we should have
bumped the GS of PIB1' and PIB2'. In other words PIB3 should have a stale GS
now (and NN should be able to remove it from the block's locations).
bq. 3. PIB1`, the first and third data internal block were down.
So in this example there are 4 failures: 2 internal data blocks, PIB1', and
PIB3. Data is not recoverable. If only 1 internal data block failed, the reader
should be able to use PIB2' for decoding.
Actually even without the help of GS, we should be able to detect stale parity
blocks from the length info in the {{.meta}} file. When decoding a partial
stripe 64KB+64KB+10KB, there are 2 scenarios:
# The last cell (which should be the only partial cell) is available. Then we
should make sure only use parity blocks with length 138KB in the {{.meta}} file.
# The last cell is unavailable. In this case, we should just make sure all
parity blocks have the same length in the {{.meta}} file.
> Erasure coding: support hflush and hsync
> ----------------------------------------
>
> Key: HDFS-7661
> URL: https://issues.apache.org/jira/browse/HDFS-7661
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Reporter: Tsz Wo Nicholas Sze
> Assignee: GAO Rui
> Attachments: EC-file-flush-and-sync-steps-plan-2015-12-01.png,
> HDFS-7661-unitTest-wip-trunk.patch,
> HDFS-EC-file-flush-sync-design-version1.1.pdf
>
>
> We also need to support hflush/hsync and visible length.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
