[ https://issues.apache.org/jira/browse/HDFS-13831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17259448#comment-17259448 ]
GeoffreyStark commented on HDFS-13831: -------------------------------------- After I changed parameter “dfs.namenode.block.deletion.increment” to 50 and parameter “dfs.namenode.storageinfo.defragment.ratio” to 0.9, RPC still maintained a high delay state when the .Trash deleted 400T files. Do you have any good suggestions?[~jianliang.wu] [~linyiqun] > Make block increment deletion number configurable > ------------------------------------------------- > > Key: HDFS-13831 > URL: https://issues.apache.org/jira/browse/HDFS-13831 > Project: Hadoop HDFS > Issue Type: Improvement > Affects Versions: 3.1.0 > Reporter: Yiqun Lin > Assignee: Ryan Wu > Priority: Major > Fix For: 2.10.0, 3.2.0, 3.0.4, 3.1.2 > > Attachments: HDFS-13831.001.patch, HDFS-13831.002.patch, > HDFS-13831.003.patch, HDFS-13831.004.patch, HDFS-13831.branch-3.0.001.patch > > > When NN deletes a large directory, it will hold the write lock long time. For > improving this, we remove the blocks in a batch way. So that other waiters > have a chance to get the lock. But right now, the batch number is a > hard-coded value. > {code} > static int BLOCK_DELETION_INCREMENT = 1000; > {code} > We can make this value configurable, so that we can control the frequency of > other waiters to get the lock chance. -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org