[ https://issues.apache.org/jira/browse/HDFS-13901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16911936#comment-16911936 ]
Jinglun commented on HDFS-13901: -------------------------------- Test the performance and patch-003 is very close to 'without any patch', so the performance won't be a problem. Hi [~jojochuang] [~hexiaoqiao], what do you think? Test Design: Test call FSNamesystem.getBlockLocations() 1,000,000 times in 3 cases: patch-002, patch-003 and without any patch. Enviroment: # Cancel the auditlog. # Set DFS_NAMENODE_ACCESSTIME_PRECISION_KEY to 1. # File path: /dir-0/dir-1/dir-2/dir-3/dir-4/file Result: ||Type||TIme cost average|| |patch-003|3890ms| |patch-002|4123ms| |without any patch|3800ms| > INode access time is ignored because of race between open and rename > -------------------------------------------------------------------- > > Key: HDFS-13901 > URL: https://issues.apache.org/jira/browse/HDFS-13901 > Project: Hadoop HDFS > Issue Type: Bug > Reporter: Jinglun > Assignee: Jinglun > Priority: Major > Attachments: HDFS-13901.000.patch, HDFS-13901.001.patch, > HDFS-13901.002.patch, HDFS-13901.003.patch > > > That's because in getBlockLocations there is a gap between readUnlock and > re-fetch write lock (to update access time). If a rename operation occurs in > the gap, the update of access time will be ignored. We can calculate new path > from the inode and use the new path to update access time. -- This message was sent by Atlassian Jira (v8.3.2#803003) --------------------------------------------------------------------- To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org