In Apache HDFS, when a DataNode starts, it registers with the NameNode. And a block report happens after some time (not atomic with the register). I haven't fully understood the code but it seems to me the NameNode treats a DataNode that has not sent its block report the same as all other DataNodes that have already reported. I get this hint because the DatanodeManger register logic does not mark a DataNode as special state like NOT_REPORTED.
Therefore the HDFS client will be able to issue read/write on the new DataNode before it finishes the report to the NameNode. Let's discuss on whether the DataNode is fresh.
If the DataNode is fresh (i.e. there is no blocks stored anyways), it is safe to use for read/write. There is nothing to read. And blocks written should be reported in the block report to the NameNode later.
If the DataNode is NOT fresh (i.e. there are data on this DataNode, somehow it went offline and back online), there may be a gap in the NameNode side metadata where some blocks exist/disappeared from the DataNode but the NameNode does not know yet. The NameNode is still holding the stale block location metadata from the previous report (if any). Will this cause inconsistencies like below (any many other edge cases of course)?
- The NameNode instructs a client to read from this DataNode but the block is in fact gone.
- The NameNode instructs a client to write to this DataNode but the block is in fact existent.
If these inconsistencies are in fact handled, what am I missing? Or if these inconsistencies do not matter, why?
Appreciate it if anyone can explain the logic in design or point me to relevant code. Thanks in advance!