hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lei (Eddy) Xu (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HDFS-10636) Modify ReplicaInfo to remove the assumption that replica metadata and data are stored in java.io.File.
Date Fri, 19 Aug 2016 23:46:20 GMT

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

Lei (Eddy) Xu edited comment on HDFS-10636 at 8/19/16 11:46 PM:
----------------------------------------------------------------

bq. If not, are there existing cases where vendors might be using FinalizedReplica for non-File
backed data?

Yea. I know vendors who have already implemented similar solutions based on {{FinalizedReplica}},
 because {{ProvidedReplica}} did not exist back to the days.  But I think it might be OK for
them if this patch did not break their code.

Another option might be that, "Finalized" looks like a state in the pipeline state machine,
instead of a "Location" where the replica is stored, IMO.  Have you considered about making
{{LocalReplica}} and {{ProvidedReplica}} being subclasses of {{FinalizedReplica}}? So that
for the pipeline state machine part of code, all the existing code can re-use the same {{FinalizedReplica}}
as what it is today.  Would love to hear your thoughts about it.


bq. Having a good test coverage seems a cleaner way to solve this. 

Agree. That would be a nice thing to do.




was (Author: eddyxu):
bq. If not, are there existing cases where vendors might be using FinalizedReplica for non-File
backed data?

Yea. I know vendors who have already implemented similar solutions based on {{FinalizedReplica}},
 because {{ProvidedReplica}} did not exist back to the days.  But I think it might be OK for
them if this patch did not break the their code.

Another option might be that, "Finalized" looks like a state in the pipeline state machine,
instead of a "Location" where the replica is stored, IMO.  Have you considered about making
{{LocalReplica}} and {{ProvidedReplica}} being subclasses of {{FinalizedReplica}}? So that
for the pipeline state machine part of code, all the existing code can re-use the same {{FinalizedReplica}}
as what it is today.  Would love to hear your thoughts about it.


bq. Having a good test coverage seems a cleaner way to solve this. 

Agree. That would be a nice thing to do.



> Modify ReplicaInfo to remove the assumption that replica metadata and data are stored
in java.io.File.
> ------------------------------------------------------------------------------------------------------
>
>                 Key: HDFS-10636
>                 URL: https://issues.apache.org/jira/browse/HDFS-10636
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: datanode, fs
>            Reporter: Virajith Jalaparti
>            Assignee: Virajith Jalaparti
>         Attachments: HDFS-10636.001.patch, HDFS-10636.002.patch, HDFS-10636.003.patch,
HDFS-10636.004.patch, HDFS-10636.005.patch
>
>
> Replace java.io.File related APIs from {{ReplicaInfo}}, and enable the definition of
new {{ReplicaInfo}} sub-classes whose metadata and data can be present on external storages
(HDFS-9806). 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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


Mime
View raw message