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

Konstantin Shvachko updated HDFS-1108:
--------------------------------------

    Attachment: hdfs-1108-habranch.txt

Two suggestions.
# {{dfs.persist.blocks}} should control whether the block(s) are {{logSync()}} 
ed. While {{persistBlocks()}} should be called unconditionally.
# When a file is closing the blocks should be {{logSync()}} ed unconditionally. 
This is current behavior, which should be retained.

For BackupNode approach it is important that blocks are persisted, that is sent 
to the backup stream. The the backup stream can then take care of delivering 
the transaction to the BackupNode. If persistBlock() is not called BackupNode 
will not have any way to know about the blocks being created.
{{logSync()}} is not required for BackupNode, but is required for your shared 
storage solution.

I think the patch should work for both approaches.
                
> Log newly allocated blocks
> --------------------------
>
>                 Key: HDFS-1108
>                 URL: https://issues.apache.org/jira/browse/HDFS-1108
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: name-node
>            Reporter: dhruba borthakur
>            Assignee: Todd Lipcon
>             Fix For: HA branch (HDFS-1623)
>
>         Attachments: HDFS-1108.patch, hdfs-1108-habranch.txt, 
> hdfs-1108-habranch.txt, hdfs-1108-habranch.txt, hdfs-1108-habranch.txt, 
> hdfs-1108-habranch.txt, hdfs-1108.txt
>
>
> The current HDFS design says that newly allocated blocks for a file are not 
> persisted in the NN transaction log when the block is allocated. Instead, a 
> hflush() or a close() on the file persists the blocks into the transaction 
> log. It would be nice if we can immediately persist newly allocated blocks 
> (as soon as they are allocated) for specific files.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to