You are viewing a plain text version of this content. The canonical link for it is here.

Posted to hdfs-issues@hadoop.apache.org by "Kihwal Lee (JIRA)" <ji...@apache.org> on 2013/07/15 22:32:50 UTC

[jira] [Resolved] (HDFS-4972) [branch-0.23] permission check and operation are done in a separate lock for getBlockLocations()

     [ https://issues.apache.org/jira/browse/HDFS-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kihwal Lee resolved HDFS-4972.
------------------------------

       Resolution: Fixed
    Fix Version/s: 0.23.10
     Hadoop Flags: Reviewed
    
> [branch-0.23] permission check and operation are done in a separate lock for getBlockLocations()
> ------------------------------------------------------------------------------------------------
>
>                 Key: HDFS-4972
>                 URL: https://issues.apache.org/jira/browse/HDFS-4972
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: namenode
>    Affects Versions: 0.23.8
>            Reporter: Kihwal Lee
>            Assignee: Kihwal Lee
>             Fix For: 0.23.10
>
>         Attachments: HDFS-4972-branch-0.23.patch
>
>
> For getBlockLocations() call, the read lock is acquired when doing permission check. But unlike other namenode methods, this is outside of the lock of the actual operation. So it ends up acquiring and releasing the lock twice.  This has two implications.
> - permissions can change in between the locks
> - the lock fairness will penalize getBlockLocations().
> This was fixed in trunk and branch-2 as a part of HDFS-4679, but not in branch-0.23.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira