[ https://issues.apache.org/jira/browse/HDFS-11552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Wang resolved HDFS-11552. -------------------------------- Resolution: Not A Problem > Erasure Coding: Support Parity Blocks placement onto same nodes hosting Data > Blocks when DataNodes are insufficient > ------------------------------------------------------------------------------------------------------------------- > > Key: HDFS-11552 > URL: https://issues.apache.org/jira/browse/HDFS-11552 > Project: Hadoop HDFS > Issue Type: Sub-task > Affects Versions: 3.0.0-alpha1 > Reporter: Manoj Govindassamy > Assignee: Manoj Govindassamy > Labels: hdfs-ec-3.0-nice-to-have > > Currently, {{DFSStripedOutputStream}} verifies if the allocated block > locations are at least numDataBlocks length. That is, for the EC Policy > RS-6-3-64K, though the total needed DNs for a full EC Block Group is 9, > Clients will be able to successfully create a DFSStripedOutputStream with > just 6 DNs. Moreover, the output stream thus created with less DNs will > totally ignore writing Parity Blocks. > {code} > [Thread-5] WARN hdfs.DFSOutputStream > (DFSStripedOutputStream.java:allocateNewBlock(497)) - Failed to get block > location for parity block, index=6 > [Thread-5] WARN hdfs.DFSOutputStream > (DFSStripedOutputStream.java:allocateNewBlock(497)) - Failed to get block > location for parity block, index=7 > [Thread-5] WARN hdfs.DFSOutputStream > (DFSStripedOutputStream.java:allocateNewBlock(497)) - Failed to get block > location for parity block, index=8 > {code} > So, upon file stream close we get the following warning message (though not > accurate) when the parity blocks are not yet written out. > {code} > INFO namenode.FSNamesystem (FSNamesystem.java:checkBlocksComplete(2726)) - > BLOCK* blk_-9223372036854775792_1002 is COMMITTED but not COMPLETE(numNodes= > 0 < minimum = 6) in file /ec/test1 > INFO hdfs.StateChange (FSNamesystem.java:completeFile(2679)) - DIR* > completeFile: /ec/test1 is closed by DFSClient_NONMAPREDUCE_-1900076771_17 > WARN hdfs.DFSOutputStream > (DFSStripedOutputStream.java:logCorruptBlocks(1117)) - Block group <1> has 3 > corrupt blocks. It's at high risk of losing data. > {code} > I am not sure if there are any practical limitations in placing more blocks > of a Block Group onto the same node. At least, we can allow parity blocks > co-exist with data blocks, whenever there are insufficient DNs in the > cluster. Later, upon addition of more DataNodes, the Block Placement Policy > can detect the improper placement for such BlockGroups and can tigger EC > reconstruction. -- This message was sent by Atlassian JIRA (v6.3.15#6346) --------------------------------------------------------------------- To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org