hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vinayakumar B (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-7645) Rolling upgrade is restoring blocks from trash multiple times
Date Thu, 26 Feb 2015 10:40:05 GMT

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

Vinayakumar B commented on HDFS-7645:

bq. The trash must be restored on rollback. Fairly easy to fix this in the same function.
If the rollback option was passed and previous exists we call doRollback. If previous does
not exist, restore trash.
This is exactly does the job when the datanode is rolled back. But problem is (as from the
beginning) entire cluster ( including those DNs who have not yet upgraded) must be restarted
with '-rollback' option to restore.

bq. On finalize, the trash directories must be deleted. I think this will be handled by signalRollingUpgrade
but I'd have to check it to make sure
Need to add downgrade also to this list. Current way of checking just the boolean status will
not work. Datanode has to be sure that NameNode is downgraded/finalized ( even should consider
multiple restart of NameNode's after this operation). but not rolled back, before deleting
the trash.
Otherwise Datanode will endup in deleting trash even for rollback of NameNode, which might
lead to block miss.

> Rolling upgrade is restoring blocks from trash multiple times
> -------------------------------------------------------------
>                 Key: HDFS-7645
>                 URL: https://issues.apache.org/jira/browse/HDFS-7645
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: datanode
>    Affects Versions: 2.6.0
>            Reporter: Nathan Roberts
>            Assignee: Keisuke Ogiwara
>         Attachments: HDFS-7645.01.patch
> When performing an HDFS rolling upgrade, the trash directory is getting restored twice
when under normal circumstances it shouldn't need to be restored at all. iiuc, the only time
these blocks should be restored is if we need to rollback a rolling upgrade. 
> On a busy cluster, this can cause significant and unnecessary block churn both on the
datanodes, and more importantly in the namenode.
> The two times this happens are:
> 1) restart of DN onto new software
> {code}
>   private void doTransition(DataNode datanode, StorageDirectory sd,
>       NamespaceInfo nsInfo, StartupOption startOpt) throws IOException {
>     if (startOpt == StartupOption.ROLLBACK && sd.getPreviousDir().exists()) {
>       Preconditions.checkState(!getTrashRootDir(sd).exists(),
>           sd.getPreviousDir() + " and " + getTrashRootDir(sd) + " should not " +
>           " both be present.");
>       doRollback(sd, nsInfo); // rollback if applicable
>     } else {
>       // Restore all the files in the trash. The restored files are retained
>       // during rolling upgrade rollback. They are deleted during rolling
>       // upgrade downgrade.
>       int restored = restoreBlockFilesFromTrash(getTrashRootDir(sd));
>       LOG.info("Restored " + restored + " block files from trash.");
>     }
> {code}
> 2) When heartbeat response no longer indicates a rollingupgrade is in progress
> {code}
>   /**
>    * Signal the current rolling upgrade status as indicated by the NN.
>    * @param inProgress true if a rolling upgrade is in progress
>    */
>   void signalRollingUpgrade(boolean inProgress) throws IOException {
>     String bpid = getBlockPoolId();
>     if (inProgress) {
>       dn.getFSDataset().enableTrash(bpid);
>       dn.getFSDataset().setRollingUpgradeMarker(bpid);
>     } else {
>       dn.getFSDataset().restoreTrash(bpid);
>       dn.getFSDataset().clearRollingUpgradeMarker(bpid);
>     }
>   }
> {code}
> HDFS-6800 and HDFS-6981 were modifying this behavior making it not completely clear whether
this is somehow intentional. 

This message was sent by Atlassian JIRA

View raw message