[
https://issues.apache.org/jira/browse/HDFS-6969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jing Zhao updated HDFS-6969:
----------------------------
Attachment: HDFS-6969.002.patch
Thanks for the review, Nicholas!
bq. i.e. use the single parameter convertStorageTypes(..) instead.
The type of {{p}} is {{List<StorageTypeProto>}}, thus we can only call
{{convertStorageTypes(List<StorageTypeProto>, int)}} here. But I think it will
better to use {{targets[i].length)}} instead of {{p.size()}}.
> Archival Storage: INode#getStoragePolicyID should always return the latest
> storage policy
> -----------------------------------------------------------------------------------------
>
> Key: HDFS-6969
> URL: https://issues.apache.org/jira/browse/HDFS-6969
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: balancer, namenode
> Reporter: Jing Zhao
> Assignee: Jing Zhao
> Attachments: HDFS-6969.000.patch, HDFS-6969.001.patch,
> HDFS-6969.002.patch
>
>
> In general, every file should only provide exact one storage policy for the
> Mover, no matter its snapshot states. Suppose a file /foo/bar, and it is
> contained in snapshots s1 and s2 of the root. If /foo/bar,
> /.snapshot/s1/foo/bar and /.snapshot/s2/foo/bar have different storage
> policies, when running Mover, we have to select one of the storage policies,
> among which the latest one should be the best. And if /foo/bar is deleted, we
> should still use its storage policy before the deletion, since the file
> deletion should not trigger data migration.
> Thus maybe what we can do is:
> 1. For a file with policy directly specified on it, alway follow the latest
> 2. Otherwise follow its latest parental path to identify its storage policy
> (simply following the parent link)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
