[ https://issues.apache.org/jira/browse/HDFS-5223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13779177#comment-13779177 ]
Nathan Roberts commented on HDFS-5223: -------------------------------------- Thanks Aaron and Todd for bringing this up. I love the flexibility of feature bits however I'm very nervous about the complexity they tend to bring. As long as there is incredibly tight controls it can work but more often than not I've seen this sort of approach lead to some incredibly unmaintainable code. The code can get very complex dealing with multiple combinations and the testing/QA can get also be very difficult to manage. Things can get overwhelmingly complex quite quickly. Having an "-enableAllNewFeatures" helps a bit but I'm not sure it lowers the complexity all that much. Of the two options, I'd lean in the direction of #1 at this point. iiuc, option 2 basically means that V2 software has to remember how to both read and write in V1 format whereas option 1 only requires that V2 be able to read V1 format (like we do today). I kind of like the fact that new software doesn't ever have to write things according to the older format. * When we update the SBN to V2 it would be allowed to come up and it would still be able to process V1 images/edits * The first time it tries to write a new image, it would do so in V2 format * When uploading a new V2 image to ANN, the upload would not proceed because of the version mismatch (this way the ANN's local storage stays purely V1) * At this point we can still rollback by simply re-bootstrapping the SBN * Now we failover to the SBN, the SBN changes the shared edits area to indicate V2 (just an update to VERSION file I think) * Upgrade old ANN with V2 software * old ANN comes up as Standby, reads the new V2 image and starts processing new V2 edits (somewhere in here also has to change local storage to V2) What's not great about this approach is that as soon as V2 software becomes active, we're writing in V2 format and at that point can't go back without losing edits. However, that's basically very similar to today's -upgrade. The only difference being that we haven't done anything to protect the blocks on the datanodes (with -upgrade we hardlink everything and therefore guarantee data blocks can't go away). So, maybe we need a mode where HDFS stops deleting blocks both from the NN's perspective (won't issue invalidates any longer), as well as from the DN side where it will ignore block deletion requests. Kind of a semi-safe-mode where the filesystem acts pretty much normally except that it refuses to delete any blocks. If we get ourselves into a true disaster-recovery situation, we can go back to V1 software + last V1 fsimage + all V1 edits that applied to that image + all blocks from the datanodes. > Allow edit log/fsimage format changes without changing layout version > --------------------------------------------------------------------- > > Key: HDFS-5223 > URL: https://issues.apache.org/jira/browse/HDFS-5223 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode > Affects Versions: 2.1.1-beta > Reporter: Aaron T. Myers > > Currently all HDFS on-disk formats are version by the single layout version. > This means that even for changes which might be backward compatible, like the > addition of a new edit log op code, we must go through the full `namenode > -upgrade' process which requires coordination with DNs, etc. HDFS should > support a lighter weight alternative. -- 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