[
https://issues.apache.org/jira/browse/HDFS-10201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15259341#comment-15259341
]
GAO Rui commented on HDFS-10201:
--------------------------------
[~liuml07], I have attached the demo patch of the new UndoLog design we have
discussed last week. The point is keeping the undo log related handling inside
of FlushUndoLogManager, and for the specific undo log of each respective
internal parity block file, both the writer and reader access the undo log via
the same instance of FlushUndoLog. By doing this way, the reader and writer
could suffer from minimum affects, almost both writing and reading undo log is
handled in datanode side, and nearly be transparent to writer and reader.
> Implement undo log in parity datanode for hflush operations
> -----------------------------------------------------------
>
> Key: HDFS-10201
> URL: https://issues.apache.org/jira/browse/HDFS-10201
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: erasure-coding
> Reporter: Mingliang Liu
> Assignee: Mingliang Liu
> Attachments: HDFS-10201-demo.patch
>
>
> According to the current design doc for hflush support in erasure coding (see
> [HDFS-7661]), the parity datanode (DN) needs an undo log for flush
> operations. After hflush/hsync, the last cell will be overwritten when 1) the
> current strip is full, 2) the file is closed, 3) or the hflush/hsync is
> called again for the current non-full stripe. To serve new reader client and
> to tolerate failures between successful hflush/hsync and overwrite operation,
> the parity DN should preserve the old cell in the undo log before overwriting
> it.
> As parities correspond to block group (BG) length and parity data of
> different BG length may have the same block length, the undo log should also
> save the respective block group (BG) length information for the flushed data.
> This jira is to track the effort of designing and implementing an undo log in
> parity DN to support hflush/hsync operations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
