In the patch it says "We don't check the last two megabytes of the edit log, in case the NameNode crashed while writing to the edit log."
Basically, if we crash while writing to the end of the log, the underlying filesystem does not give us the guarantees we would need to get every byte perfect. Consider the following sequence of events:
1. NN allocates an extra 1 MB at the end of the file and fills it with 0xff bytes
2. NN writes an opcode to the edit log file. It happens to span two sectors on the hard disk
3. The kernel writes the second half of the opcode to disk
4. system crash
In this case, we're left with a file that looks like this:
0xff 0xff 0xff 0xff ... [opcode bytes]... 0xff 0xff 0xff
This would clearly fail validation. Hence the NameNode would fail to start, even though no data has been lost (the opcode was never acked to the client). This would be a serious problem. UNCHECKED_REGION_LENGTH fixes this problem.
We can't control the order in which the kernel flushes sectors out of the buffer cache and on to the hard disk. We can set up barriers (that is what fsync is), but control of the ordering is beyond us.