[ https://issues.apache.org/jira/browse/HDFS-1245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Konstantin Shvachko updated HDFS-1245: -------------------------------------- Assignee: Konstantin Shvachko (was: Dmytro Molkov) Target Version/s: 2.0.3-alpha Affects Version/s: 0.22.0 Status: Patch Available (was: Open) > Plugable block id generation > ----------------------------- > > Key: HDFS-1245 > URL: https://issues.apache.org/jira/browse/HDFS-1245 > Project: Hadoop HDFS > Issue Type: New Feature > Components: namenode > Affects Versions: 0.22.0 > Reporter: Dmytro Molkov > Assignee: Konstantin Shvachko > Attachments: blockIdGenerator.patch > > > The idea is to have a way to easily create block id generation engines that > may fit a certain purpose. One of them could be HDFS-898 started by > Konstantin, but potentially others. > We chatted with Dhruba about this for a while and came up with the following > approach: > There should be a BlockIDGenerator interface that has following methods: > void blockAdded(Block) > void blockRemoved(Block) > Block nextBlock() > First two methods are needed for block generation engines that hold a certain > state. During the restart, when namenode reads the fsimage it will notify > generator about all the blocks it reads from the image and during runtime > namenode will notify the generator about block removals on file deletion. > The instance of the generator will also have a reference to the block > registry, the interface that BlockManager implements. The only method there > is __blockExists(Block)__, so that the current random block id generation can > be implemented, since it needs to check with the block manager if the id is > already present. > What does the community think about this proposal? -- 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