[
https://issues.apache.org/jira/browse/HDFS-13310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16421497#comment-16421497
]
Ewan Higgs commented on HDFS-13310:
-----------------------------------
Hi Daryn,
{quote}I don't understand why the DN needs all kinds of new commands (here and
other jiras) that are equivalent to "copy or move this block". If you want to
do multi-part upload to s3 magic, that should be hidden behind the "provided"
plugin when a block is copied/moved to it.
{quote}
I know you've been following this project but to clear up any confusion let me
restate that a goal/constraint that we are working with here is that we would
like the synchronization end point to work at the file level and not the block
level. So any command to the DN to copy a block needs to be part of a
collection of blocks all being copied together. The current BlockCommand
protocol treats all blocks independently since DNs don't really have a concept
of a file; only blocks. This is the reason we want a new command.
{quote}Is there any way to generalize this feature?
{quote}
Optimally we would love to reuse existing commands where it makes sense.
Therefore, the first question is: can we reuse DNA_TRANSFER? DNA_TRANSFER looks
like the following:
{quote}
{{/**}}
{{* Command to instruct datanodes to perform certain action}}
{{* on the given set of blocks.}}
{{*/}}
{{message BlockCommandProto {}}
{{ enum Action {}}
{{ TRANSFER = 1; // Transfer blocks to another datanode}}
{{ INVALIDATE = 2; // Invalidate blocks}}
{{ SHUTDOWN = 3; // Shutdown the datanode}}
{{ }}}
{{ }}
{{ required Action action = 1;}}
{{ required string blockPoolId = 2;}}
{{ repeated BlockProto blocks = 3;}}
{{ repeated DatanodeInfosProto targets = 4;}}
{{ repeated StorageUuidsProto targetStorageUuids = 5;}}
{{ repeated StorageTypesProto targetStorageTypes = 6;}}
{{}}}
{quote}
As we are not writing to another Datanode per se, DatanodeInfosProto is not an
adequate field for defining a target so this could be used with some extension.
We /could/ write to a Datanode with the Provided Storage as the
targetStorageUuid, but remember: we can't just move the block to the external
storage endpoint without context of the whole file so this won't work (afaics).
So we need a new command (of DatanodeCommandProto.Type). You call this a leaky
abstraction, but there is no abstraction going on: it's a command to do exactly
what the command name is. I guess one could take exception here that we are
tying it directly to the ability to synchronize files instead of offering
something like DNA_GROUP_TRANSFER_PART to denote that we are transferring the
block as part of a group. Such a command could be reused by anyone who needs to
do such a thing (Maybe HDFS-10419 (HDSL) could use this?)
Another approach could be to reuse BlockCommandProto/DNA_TRANSFER and introduce
a new sum type for the target consisting of DataNodeAndStorage (existing case),
PutFile/PutFilePart (for our use case), and e.g. Maybe HDFS-10419 will call for
a DataNodeAndContainer in case we want some new container repacking command.
Further, it would change the semantics of DNA_TRANSFER when writing a file
part: 1. we don't want to delete successfully migrated blocks until the entire
multipart write has been completed and 2. we need to support multiple replicas
of a block on the same node (to implement 1).
> [PROVIDED Phase 2] The DatanodeProtocol should be have DNA_BACKUP to backup
> blocks
> ----------------------------------------------------------------------------------
>
> Key: HDFS-13310
> URL: https://issues.apache.org/jira/browse/HDFS-13310
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Reporter: Ewan Higgs
> Assignee: Ewan Higgs
> Priority: Major
> Attachments: HDFS-13310-HDFS-12090.001.patch,
> HDFS-13310-HDFS-12090.002.patch
>
>
> As part of HDFS-12090, Datanodes should be able to receive DatanodeCommands
> in the heartbeat response that instructs it to backup a block.
> This should take the form of two sub commands: PUT_FILE (when the file is <=1
> block in size) and MULTIPART_PUT_PART when part of a Multipart Upload (see
> HDFS-13186).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
