[
https://issues.apache.org/jira/browse/HDFS-7430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14223998#comment-14223998
]
Colin Patrick McCabe commented on HDFS-7430:
--------------------------------------------
* Fix issue with {{stats.nextBlockPoolScanStartMs}}
* {{VolumeScanner#Statistics}} should have a {{toString}} method.
* {{TestOverReplicatedBlocks}}: test needs a slightly different way of manually
triggering the block scanner
* {{BlockReportTestBase}}:
{{DFSConfigKeys.DFS_DATANODE_DIRECTORYSCAN_INTERVAL_KEY}} is in seconds, but
the test was treating it as milliseconds.
* {{SnapshotTestHelper}}: the old {{setLevel2OFF}} function for
programmatically changing unit test logging no longer works (and throws an
exception), because some of the loggers are actually slf4j loggers, not log4j.
Got rid of {{setLevel2OFF}} and added a more sophisticated set of methods to
{{GenericTestUtils}} that can programmatically disable or change logging for
either commons-logging, slf4j, or log4j loggers, without making the caller care
about which is which.
> Refactor the BlockScanner to use O(1) memory and use multiple threads
> ---------------------------------------------------------------------
>
> Key: HDFS-7430
> URL: https://issues.apache.org/jira/browse/HDFS-7430
> Project: Hadoop HDFS
> Issue Type: Improvement
> Affects Versions: 2.7.0
> Reporter: Colin Patrick McCabe
> Assignee: Colin Patrick McCabe
> Attachments: HDFS-7430.002.patch, HDFS-7430.003.patch, memory.png
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)