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 "Andrew Wang (JIRA)" <ji...@apache.org> on 2013/02/28 20:43:14 UTC
[jira] [Commented] (HDFS-4526) If persistBlocks enabled in
Namenode, hflush call can avoid persisting blocks with fsync
[ 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