[HDFS-8999] Allow a file to be closed with COMMITTED but not yet COMPLETE blocks.

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 2.8.0, 3.0.0-alpha1
• Component/s: namenode
• Hadoop Flags: Reviewed
• Assignee: Tsz-wo Sze
• Reporter: Jitendra Nath Pandey
• Created: 01/Sep/15 17:21
• Updated: 18/May/20 17:28
• Resolved: 28/Jan/16 02:45

Description

This comes out of a discussion in HDFS-8763. Pasting jingzhao's comment from the jira:

...whether we need to let NameNode wait for all the block_received msgs to announce the replica is safe. Looking into the code, now we have

1. NameNode knows the DataNodes involved when initially setting up the writing pipeline
2. If any DataNode fails during the writing, client bumps the GS and finally reports all the DataNodes included in the new pipeline to NameNode through the updatePipeline RPC.
3. When the client received the ack for the last packet of the block (and before the client tries to close the file on NameNode), the replica has been finalized in all the DataNodes.

Then in this case, when NameNode receives the close request from the client, the NameNode already knows the latest replicas for the block. Currently the checkReplication call only counts in all the replicas that NN has already received the block_received msg, but based on the above #2 and #3, it may be safe to also count in all the replicas in the BlockUnderConstructionFeature#replicas?

Issue Links

• is related to: HDFS-1172 Blocks in newly completed files are considered under-replicated too quickly
• is related to: HDFS-10810 Setreplication removing block from underconstrcution temporarily when batch IBR is enabled.
• is related to: HDFS-8344 NameNode doesn't recover lease for files with missing blocks
• is related to: HDFS-9710 Change DN to send block receipt IBRs in batches
• is related to: HDFS-15359 EC: Allow closing a file with committed blocks
• relates to: HDFS-15359 EC: Allow closing a file with committed blocks