[
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.branch-1.02.patch
Thank you Chris! I just realized the v1 patch had failed to wrap the logging
call in {{isTraceEnabled}}.
Attaching v2 patch for branch-1. I will hold off on committing the v2 trunk
patch until tonight in case Suresh has any comments.
> 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.02.patch, 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)
