[
https://issues.apache.org/jira/browse/HDFS-12665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245119#comment-16245119
]
Virajith Jalaparti commented on HDFS-12665:
-------------------------------------------
Thanks for the updated patch [~ehiggs]. I took a look at it and made the
following changes for v5 (attached now).
- removed unnecessary parameters in hdfs-default.xml
({{dfs.datanode.block.provider.class}}, {{dfs.provided.blockformat.class}},
{{dfs.namenode.block.provider.class}})
- Changed the names of the new parameters (in {{DFSConfigKeys}}) to add more
context to them.
- Rename {{ITAliasMap}} to {{ITestInMemoryAliasMap}} and {{TestAliasMap}} to
{{TestInMemoryAliasMap}}
- Reverted change from {{TestFileRegionBlockAliasMap}} to
{{TestFileRegionProvider}}
- Added back the checks for block pool id in
{{ProvidedVolumeImpl.compileReport}} and {{ProviderBlockIteratorImpl#nextBlock}}
- modified some of comments as they were circular.
- Fixed some checkstyle issues.
- Renamed {{InMemoryAliasMapProtocolTranslatorPB}} to
{{InMemoryAliasMapProtocolClientSideTranslatorPB}}
- Added a {{DFS_PROVIDED_ALIASMAP_INMEMORY_RPC_ADDRESS_DEFAULT}} as a default
RPC address for the In memory alias map
- Replace {{assertThat}} with {{assertTrue}}, {{assertFalse}} and
{{assertEquals}} as required, in various places.
- Move the tests from {{TestMultiThreadedAliasMapClient}} to
{{TestInMemoryLevelDBAliasMapClient}}
- I don't understand what {{TestNameNodeLevelDbProvidedImplementation}} really
tests. The {{writeRead()}} and {{list()}}
methods seem to be creating files even though we can't really create provided
files. Also, the {{createImage()}} function, doesn't traverse the provided
directory to create an image. So, it is not really testing the use of the
InMemoryAliasMap by the NN and DN. I replaced these tests with
{{TestNameNodeProvidedImplementation#testInMemoryAliasMap}}.
- Reverted the change in {{TreePath#writeBlock}} to retain the block pool id.
A few questions:
- {{InMemoryAliasMap}} uses
{{LoggerFactory.getLogger(InMemoryLevelDBAliasMapServer.class)}}. Was this
intentional?
- Should we rename {{InMemoryAliasMap}} to {{InMemoryLevelDBAliasMap}}, similar
to the other classes?
- Why add a new {{iterator()}} to {{BlockAliasMap}} and not use the
{{BlockAliasMap.Reader}}?
*Blockers which need to be fixed*:
# {{TestNameNodeProvidedImplementation#testInMemoryAliasMap}} fails. This is
because the block pool id is set to NULL for all FileRegions written to
leveldb. As a result, the {{ProvidedVolumeImpl}} doesn't the blocks properly.
We need to store the block pool id along with the blocks. My proposal for now
is to just have {{FileRegion}} as the value in leveldb so that block pool id
can be retrieved. Breaking down {{FileRegion}} into a (key,value) pair can be
done as part of HDFS-12713. What do you think?
# {{InMemoryLevelDBAliasMapClient#LevelDbWriter}} doesn't work without a
running server. The image generation tool doesn't start a server before using
{{BlockAliasMap#getWriter()}}. {{LevelDbWriter}} needs to be modified to make
sure that it alone is sufficient to write information on block aliases to the
level db store.
> [AliasMap] Create a version of the AliasMap that runs in memory in the
> Namenode (leveldb)
> -----------------------------------------------------------------------------------------
>
> Key: HDFS-12665
> URL: https://issues.apache.org/jira/browse/HDFS-12665
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Reporter: Ewan Higgs
> Assignee: Ewan Higgs
> Attachments: HDFS-12665-HDFS-9806.001.patch,
> HDFS-12665-HDFS-9806.002.patch, HDFS-12665-HDFS-9806.003.patch,
> HDFS-12665-HDFS-9806.004.patch, HDFS-12665-HDFS-9806.005.patch
>
>
> The design of Provided Storage requires the use of an AliasMap to manage the
> mapping between blocks of files on the local HDFS and ranges of files on a
> remote storage system. To reduce load from the Namenode, this can be done
> using a pluggable external service (e.g. AzureTable, Cassandra, Ratis).
> However, to aide adoption and ease of deployment, we propose an in memory
> version.
> This AliasMap will be a wrapper around LevelDB (already a dependency from the
> Timeline Service) and use protobuf for the key (blockpool, blockid, and
> genstamp) and the value (url, offset, length, nonce). The in memory service
> will also have a configurable port on which it will listen for updates from
> Storage Policy Satisfier (SPS) Coordinating Datanodes (C-DN).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
