[
https://issues.apache.org/jira/browse/HDFS-7081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jing Zhao updated HDFS-7081:
----------------------------
Attachment: HDFS-7081.004.patch
Update the patch to change the namespace to SYSTEM.
bq. Basically, do not set UNSPECIFIED on files. At create time, a files sets
its storage policy either to an inherited parent policy, or the default policy.
Actually this may cause other issue. Initially users may not set any storage
policies. Then with the above strategy all the new files will be set with the
default policy (currently it's HOT). Then let's say the user wants to set a
directory to some other policy for the first time. The user/system now has to
not only set the policy on the directory, but also scan the whole subtree to
change the policy of those files.
And "rename" may not be a serious issue here. First, the migration only happens
when running the Mover tool. Also, sometimes I think users may want to use
rename to change a file's storage policy. A unspecified storage policy means
this file/dir follows the storage policy of its nearest ancestor. I can see use
cases that users set a more transient storage policy for /tmp and later if a
file is moved out a more durable storage policy is automatically applied to it.
> Add new DistributedFileSystem API for getting all the existing storage
> policies
> -------------------------------------------------------------------------------
>
> Key: HDFS-7081
> URL: https://issues.apache.org/jira/browse/HDFS-7081
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: balancer, namenode
> Reporter: Jing Zhao
> Assignee: Jing Zhao
> Attachments: HDFS-7081.000.patch, HDFS-7081.001.patch,
> HDFS-7081.002.patch, HDFS-7081.003.patch, HDFS-7081.004.patch
>
>
> Instead of loading all the policies from a client side configuration file, it
> may be better to provide Mover with a new RPC call for getting all the
> storage policies from the namenode.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
