hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daryn Sharp (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-4186) logSync() is called with the write lock held while releasing lease
Date Wed, 14 Nov 2012 23:36:13 GMT

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

Daryn Sharp commented on HDFS-4186:
-----------------------------------

I think the patch looks generally good, except when it bails out early on {{if (!oldest.expiredHardLimit())}}.
 I think it should return {{needSync}} instead of false?  Minor nit is "happenned" is misspelled.

bq. Maybe I'm being too nit picky, but I'd rather see the optimization around skipping logSync
when nothing has been logged separate from this bug fix for lease recovery.

While we could break this into another jira if you feel strongly, I think the latest patch
seems pretty simple in nature.  I think it's esp. good in the sense of not generating bad
metrics.  If we are going to track a number, it should probably be an accurate number.  I
think that was a pretty good catch by Kihwal.

                
> logSync() is called with the write lock held while releasing lease
> ------------------------------------------------------------------
>
>                 Key: HDFS-4186
>                 URL: https://issues.apache.org/jira/browse/HDFS-4186
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: name-node
>    Affects Versions: 0.23.4, 2.0.2-alpha
>            Reporter: Kihwal Lee
>            Assignee: Kihwal Lee
>            Priority: Critical
>         Attachments: hdfs-4186-branch-0.23-inaccurate-batched-sync-count.patch, hdfs-4186-trunk-inaccurate-batched-sync-count.patch,
hdfs-4186-trunk.patch
>
>
> As pointed out in HDFS-4138, when the lease monitor calls internalReleaseLease(), it
acquires the namespace write lock. Inside internalReleaseLease(), if a block recovery is needed,
the lease is reassigned to the namenode itself and this is logged & synced in logReassignLease().
> Since this is done while the write lock is held, log syncing is blocked. When a large
number of leases are expired and blocks are recovered, namenode can slow down.

--
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

Mime
View raw message