[
https://issues.apache.org/jira/browse/HDFS-7503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arpit Agarwal updated HDFS-7503:
--------------------------------
Attachment: HDFS-7503.trunk.02.patch
Thanks for the review Suresh.
bq. One concern I had was if this information is useful for debugging.
Here is an alternate patch for trunk that logs invalidated blocks outside
theNameSystem write lock.
Separately perhaps it is time to use async appenders for
blockLog/blockStateChangeLog.
> Namenode restart after large deletions can cause slow processReport (due to
> logging)
> ------------------------------------------------------------------------------------
>
> Key: HDFS-7503
> URL: https://issues.apache.org/jira/browse/HDFS-7503
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
> Affects Versions: 1.2.1, 2.6.0
> Reporter: Arpit Agarwal
> Assignee: Arpit Agarwal
> Attachments: HDFS-7503.branch-1.patch, HDFS-7503.trunk.01.patch,
> HDFS-7503.trunk.02.patch
>
>
> If a large directory is deleted and namenode is immediately restarted, there
> are a lot of blocks that do not belong to any file. This results in a log:
> {code}
> 2014-11-08 03:11:45,584 INFO BlockStateChange
> (BlockManager.java:processReport(1901)) - BLOCK* processReport:
> blk_1074250282_509532 on 172.31.44.17:1019 size 6 does not belong to any file.
> {code}
> This log is printed within FSNamsystem lock. This can cause namenode to take
> long time in coming out of safemode.
> One solution is to downgrade the logging level.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
