[
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: [email protected]
For additional commands, e-mail: [email protected]
