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

Tsz Wo Nicholas Sze commented on HDFS-9821:
-------------------------------------------

> Not all keys have the unit as part of their name. Related keys may use 
> different units e.g. dfs.blockreport.intervalMsec accepts msec while 
> dfs.blockreport.initialDelay accepts seconds. ...

It does not matter if the unit is a part of the name since a unit is predefined 
in both cases, e.g. dfs.blockreport.intervalMsec defines its unit explicitly 
and dfs.blockreport.initialDelay defines its unit implicitly.

Why don't we keep the existing configuration as-is and use the predefined unit 
as the default unit?  When the value is set without a unit, the default unit is 
used.  When it is set with a unit, the default unit is overridden.

> HDFS configuration should accept friendly time units
> ----------------------------------------------------
>
>                 Key: HDFS-9821
>                 URL: https://issues.apache.org/jira/browse/HDFS-9821
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: datanode, namenode
>    Affects Versions: 2.8.0
>            Reporter: Arpit Agarwal
>            Assignee: Xiaobing Zhou
>
> HDFS configuration keys that define time intervals use units inconsistently 
> (Hours, seconds, milliseconds).
> Not all keys have the unit as part of their name. Related keys may use 
> different units e.g. {{dfs.blockreport.intervalMsec}} accepts msec while 
> {{dfs.blockreport.initialDelay}} accepts seconds. Milliseconds is rarely 
> useful as a time unit which makes these values hard to parse when reading 
> config files.
> We can either
> # Let existing keys use friendly units e.g. 60s, 5m, 1d, 6w etc. This can be 
> done compatibly since there will be no conflict with existing valid 
> configuration.
> # Just deprecate the existing keys and define new ones that accept friendly 
> units.



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

Reply via email to