[
https://issues.apache.org/jira/browse/HDFS-11130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15658724#comment-15658724
]
Anu Engineer commented on HDFS-11130:
-------------------------------------
[~vagarychen] Thanks for posting this patch. It looks quite good. I had a
comment which can be handled in a later JIRA if you think it easier to do so.
The container IDs are returned or serialized via, {{repeated string
allContainerIDs = 6;}} . Both our read and write operations will depend on the
order being always correct. That is when we want to read block0, we have to
locate the first container.
I know that protoc or levelDB serialization is such that it is unlikely to mess
this information up. However, what bothers me is that we have no way of knowing
if we mess up this information.
Would it make sense to create a
{noformat}
message ContainerIDProto {
required string containerID = 1;
required uint64 index = 2;
}
{noformat}
Then we could replace {{repeated string allContainerIDs = 6;}} with
{{repeated ContainerIDProto allContainerIDs = 6;}}.
This has the advantage we have a check variable, the sorted order of the array
and actual index value which allows us to verify that we are accessing the
right container.
If we do this I am hoping we will be persisting {{ContainerIDProto}} in the
createVolume API in cBlock Server.
> Block Storage : add storage client to server protocol
> -----------------------------------------------------
>
> Key: HDFS-11130
> URL: https://issues.apache.org/jira/browse/HDFS-11130
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: hdfs
> Reporter: Chen Liang
> Assignee: Chen Liang
> Attachments: HDFS-11130-HDFS-7240.001.patch
>
>
> This JIRA adds the protocol between block storage client side and server
> side. For now, the only operation is mount volume. More specifically, when
> user mount a volume on client side, client checks with server to verify
> whether it is a valid volume to mount. On valid mount request, server will
> also piggyback meta information about the volume back to client.
> Note that the actual read/write on the volume will never go through server,
> as long as volume is mounted on client, it is all client's job to communicate
> with the underly storage layer (SCM in this case)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
