hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Wang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-4526) If persistBlocks enabled in Namenode, hflush call can avoid persisting blocks with fsync
Date Thu, 28 Feb 2013 19:43:14 GMT

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

Andrew Wang commented on HDFS-4526:
-----------------------------------

Hi Uma,

I'm not super familiar with the write path, but I was wondering: how are readers updated of
the new block length after an {{hsync/hflush}} if we're skipping the {{fsync}}? Isn't that
part of the {{hsync/hflush}} semantics?

Having an explanatory comment on the if/return might be nice.
                
> If persistBlocks enabled in Namenode, hflush call can avoid persisting blocks with fsync
> ----------------------------------------------------------------------------------------
>
>                 Key: HDFS-4526
>                 URL: https://issues.apache.org/jira/browse/HDFS-4526
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: namenode
>    Affects Versions: 3.0.0, 2.0.3-alpha
>            Reporter: Uma Maheswara Rao G
>            Assignee: Uma Maheswara Rao G
>         Attachments: HDFS-4526.patch
>
>
> If persists blocks enabled/in HA, evenry getAdditionalBlock will persist the blocks.
> So, if user calls Hflush, then client can simply ensure data flushed to DNs and need
not worry about fsync. 
> Since we can not depend upon client side configuration about persistBlocks, we can just
make a fsync call to NN and check whether persistBlocks enabled. If it is enabled, then simply
return as it would have already persisted. So, that below peice of code execution can be avoided
for every blocks and hflush calls
> from fsync:
> {code}
>  writeLock();
>     try {
>       checkOperation(OperationCategory.WRITE);
>       if (isInSafeMode()) {
>         throw new SafeModeException("Cannot fsync file " + src, safeMode);
>       }
>       INodeFileUnderConstruction pendingFile  = checkLease(src, clientName);
>       dir.persistBlocks(src, pendingFile);
>     } finally {
>       writeUnlock();
>     }
>     getEditLog().logSync();
> {code}

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