hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rakesh R (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-10285) Storage Policy Satisfier in Namenode
Date Fri, 28 Jul 2017 09:41:01 GMT

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

Rakesh R commented on HDFS-10285:
---------------------------------

Thanks a lot [~andrew.wang] for the reviews.

bq. Should dfs.storage.policy.satisfier.activate default to false for now?
During NN startup, SPS feature initializes satisfy thread and will stay idle until user tells
to satisfy storage policy for a given path. So, there won't be much overhead to the Namenode
process as the thread will be idle. Also, the system test report(attached to the jira) and
Jenkins unit testing results shows the feature is stable. Since we have dynamic switch on/off
mechanism via reconfig, I'm OK to disable by default if there is any concern, should I ?

bq. Might also rename this to "enabled" rather than "activate" to align with other previous
config keys.
Agreed, I will raise a sub-task and change the configuration name asap.

bq. What happens during a rolling upgrade? Will DNs ignore the unknown message, and NN handle
this correctly?
Yes, DN will ignore the unknown message. On the othe other side, NN will wait for certain
configured amount of time for the block movement response. After this period, if there is
no response NN will retry scheduling the block movement. So, no issues with rolling upgrade.

bq. On downgrade, I assume the xattrs just stay there ignored.
Yes, exactly it will be ignored.

> Storage Policy Satisfier in Namenode
> ------------------------------------
>
>                 Key: HDFS-10285
>                 URL: https://issues.apache.org/jira/browse/HDFS-10285
>             Project: Hadoop HDFS
>          Issue Type: New Feature
>          Components: datanode, namenode
>    Affects Versions: HDFS-10285
>            Reporter: Uma Maheswara Rao G
>            Assignee: Uma Maheswara Rao G
>         Attachments: HDFS-10285-consolidated-merge-patch-00.patch, HDFS-10285-consolidated-merge-patch-01.patch,
HDFS-SPS-TestReport-20170708.pdf, Storage-Policy-Satisfier-in-HDFS-June-20-2017.pdf, Storage-Policy-Satisfier-in-HDFS-May10.pdf
>
>
> Heterogeneous storage in HDFS introduced the concept of storage policy. These policies
can be set on directory/file to specify the user preference, where to store the physical block.
When user set the storage policy before writing data, then the blocks could take advantage
of storage policy preferences and stores physical block accordingly. 
> If user set the storage policy after writing and completing the file, then the blocks
would have been written with default storage policy (nothing but DISK). User has to run the
‘Mover tool’ explicitly by specifying all such file names as a list. In some distributed
system scenarios (ex: HBase) it would be difficult to collect all the files and run the tool
as different nodes can write files separately and file can have different paths.
> Another scenarios is, when user rename the files from one effected storage policy file
(inherited policy from parent directory) to another storage policy effected directory, it
will not copy inherited storage policy from source. So it will take effect from destination
file/dir parent storage policy. This rename operation is just a metadata change in Namenode.
The physical blocks still remain with source storage policy.
> So, Tracking all such business logic based file names could be difficult for admins from
distributed nodes(ex: region servers) and running the Mover tool. 
> Here the proposal is to provide an API from Namenode itself for trigger the storage policy
satisfaction. A Daemon thread inside Namenode should track such calls and process to DN as
movement commands. 
> Will post the detailed design thoughts document soon. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
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