hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron T. Myers (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-4777) File creation with overwrite flag set to true results in logSync holding namesystem lock
Date Tue, 30 Apr 2013 16:54:16 GMT

    [ https://issues.apache.org/jira/browse/HDFS-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13645717#comment-13645717

Aaron T. Myers commented on HDFS-4777:

Thanks a lot for working on this, Suresh.

>From a quick look it seems like most (all?) of these test failures fall into three categories:

# Holding the lock during sync because of the startFile/deleteInternal issue you initially
identified in this JIRA.
# Holding the lock when calling FSNS#logUpdateMasterKey when updating token secret keys.
# Holding the lock when calling FSNS#logSyncAll when entering safe mode.

The first two definitely seem like they should be fixed. The third I'm not so sure can/should
be fixed, since we're not really concerned about NN operation throughput when entering safemode,
and it does seem to be a good idea to call logSyncAll when entering SM.

Certainly feel free to make sub-tasks if you want, though it doesn't seem crazy to me to do
this in one JIRA. I don't think it will actually require changing all that many places.
> File creation with overwrite flag set to true results in logSync holding namesystem lock
> ----------------------------------------------------------------------------------------
>                 Key: HDFS-4777
>                 URL: https://issues.apache.org/jira/browse/HDFS-4777
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: namenode
>    Affects Versions: 0.23.0, 2.0.0-alpha
>            Reporter: Suresh Srinivas
>            Assignee: Suresh Srinivas
>            Priority: Blocker
>         Attachments: HDFS-4777.patch
> FSNamesystem#startFileInternal calls delete. Delete method releases the write lock, making
parts of startFileInternal code unintentionally executed without write lock being held.

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

View raw message