Description
We should update the BlockScanner to use a constant amount of memory by keeping track of what block was scanned last, rather than by tracking the scan status of all blocks in memory. Also, instead of having just one thread, we should have a verification thread per hard disk (or other volume), scanning at a configurable rate of bytes per second.
Attachments
Attachments
Issue Links
- breaks
-
HDFS-9190 VolumeScanner throwing NPE while scanning suspect block.
- Resolved
-
HDFS-7633 BlockPoolSliceScanner fails when Datanode has too many blocks
- Resolved
-
HDFS-7686 Re-add rapid rescan of possibly corrupt block feature to the block scanner
- Closed
-
HDFS-8681 BlockScanner is incorrectly disabled by default
- Closed
-
HDFS-12209 VolumeScanner scan cursor not save periodic
- Patch Available
- incorporates
-
HDFS-6111 Avoid duplicate entries in Block Scan verification logs
- Resolved
-
HDFS-6147 New blocks scanning will be delayed due to issue in BlockPoolSliceScanner#updateBytesToScan(..)
- Resolved
- is duplicated by
-
HDFS-7532 dncp_block_verification.log.prev too large
- Resolved
-
HDFS-8028 TestNNHandlesBlockReportPerStorage/TestNNHandlesCombinedBlockReport Failed after patched HDFS-7704
- Resolved
- is related to
-
HDFS-8691 Cleanup BlockScanner initialization and add test for configuration contract
- Open
-
HDFS-3488 BlockPoolSliceScanner#getNewBlockScanTime does not handle numbers > 31 bits properly
- Resolved
-
HDFS-7721 The HDFS BlockScanner may run fast during the first hour
- Closed
- supercedes
-
HDFS-4224 The dncp_block_verification log can be compressed
- Resolved