hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chen Liang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-11138) Block Storage : add block storage server
Date Fri, 18 Nov 2016 00:52:58 GMT

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

Chen Liang commented on HDFS-11138:

Thanks [~anu] for the comments! Again here are some thoughts I had (mainly related to 3 &
4 & 6). And will address the rest in the next path.

I know that keeping a map AND a list in StorageManager is not quite clean. The idea was that
I wanted to allow two ways of accessing containers:
1. access them from the first to the last, based on their order index - which requires a list
2. access a specific a container with a given containerID - which requires a map
This was my very first design when writing the class. 

So far, we access all containers at once on mount time by returning all the containers along
with their order, in which case a list is sufficient. I wanted to leave the possibility for
accessing a container by key on server side, but I can't really think of a use case for the
time being... Do you think this access-by-key is not worth keeping? If so, I'll just go remove

> Block Storage : add block storage server
> ----------------------------------------
>                 Key: HDFS-11138
>                 URL: https://issues.apache.org/jira/browse/HDFS-11138
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: hdfs
>            Reporter: Chen Liang
>            Assignee: Chen Liang
>         Attachments: HDFS-11138-HDFS-7240.001.patch, HDFS-11138-HDFS-7240.002.patch,
HDFS-11138-HDFS-7240.003.patch, HDFS-11138-HDFS-7240.004.patch
> This JIRA adds the skeleton for server side code, which is one of the core components
in block storage. For performance concerns, the server does not handle any actual read/write
operation but serving primarily as a meta data server. It provides four APIs:
> # create volume : which will call into underlying container layer to allocate containers
> # delete volume : delete a specific volume (as well as its containers)
> # info volume : return information of a specific volume
> # list volume : list all volumes
> Note that this is still subject to potentially major changes. Features such as persistence
are missing.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org

View raw message