[
https://issues.apache.org/jira/browse/HDFS-8269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14515870#comment-14515870
]
Jing Zhao commented on HDFS-8269:
---------------------------------
Thanks for the fix, Haohui. The patch looks good to me. Some comments:
# Looks like {{GetBlockLocationsResult#iip}} can now be replaced by a boolean
indicating whether to update access time.
# If the given {{srcArg}} is a reserved path (suppose it is mapped to
/foo/bar), and if between the read and write lock the original /foo/bar is
deleted and another file is named as /foo/bar, then the following code will
update the access time of the wrong file.
{code}
+ // Resolve the path again and update the atime only when the file
+ // exists
+ final INodesInPath iip = dir.getINodesInPath(src, true);
{code}
# Maybe we can also add an extra test {{testGetBlockLocationsRacingWithRename}}
to catch the above case?
> getBlockLocations() does not resolve the .reserved path and generates
> incorrect edit logs when updating the atime
> -----------------------------------------------------------------------------------------------------------------
>
> Key: HDFS-8269
> URL: https://issues.apache.org/jira/browse/HDFS-8269
> Project: Hadoop HDFS
> Issue Type: Bug
> Reporter: Yesha Vora
> Assignee: Haohui Mai
> Priority: Blocker
> Attachments: HDFS-8269.000.patch
>
>
> When {{FSNamesystem#getBlockLocations}} updates the access time of the INode,
> it uses the path passed from the client, which generates incorrect edit logs
> entries:
> {noformat}
> <RECORD>
> <OPCODE>OP_TIMES</OPCODE>
> <DATA>
> <TXID>5085</TXID>
> <LENGTH>0</LENGTH>
> <PATH>/.reserved/.inodes/18230</PATH>
> <MTIME>-1</MTIME>
> <ATIME>1429908236392</ATIME>
> </DATA>
> </RECORD>
> {noformat}
> Note that the NN does not resolve the {{/.reserved}} path when processing the
> edit log, therefore it eventually leads to a NPE when loading the edit logs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
