[
https://issues.apache.org/jira/browse/HDFS-13901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16937047#comment-16937047
]
Wei-Chiu Chuang commented on HDFS-13901:
----------------------------------------
Thanks for the update and the awesome benchmark result.
I think the fix itself is good, and easy to understand.
Should we remove the following comment? Looks to me this is the exact same bug
fixed here.
{code}
* XXX: Races can still occur even after resolving the path again.
* For example:
*
* <ul>
* <li>Get the block location for "/a/b"</li>
* <li>Rename "/a/b" to "/c/b"</li>
* <li>The second resolution still points to "/a/b", which is
* wrong.</li>
* </ul>
*
* The behavior is incorrect but consistent with the one before
* HDFS-7463. A better fix is to change the edit log of SetTime to
* use inode id instead of a path.
*/
{code}
Test:
optional but you can replace the following
{code}
OutputStream out = hdfs.create(new Path(src));
out.write("hello".getBytes());
out.close();
{code}
with
{code}
DFSTestUtil.createFile(hdfsfs, new Path(src), len,
(short) 1, 0xFEED)
{code}
Can you use something else other than sleep 1ms? Like CountDownLatch or
semaphore? Using sleep 1ms to control order of threads is almost always going
to create flaky tests.
> 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, HDFS-13901.004.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.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
