[
https://issues.apache.org/jira/browse/HDFS-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794567#comment-13794567
]
Colin Patrick McCabe commented on HDFS-5358:
--------------------------------------------
bq. Can we use uint32 for replication in the protocol? This would further
prevent a negative value, and also it would be consistent with the replication
field in other protocol messages. (See example below.)
OK. I will change it to use this for consistency.
bq. Higher-level question, what do you think about a "cache all" replication
factor...
Let's worry about having a "cache all" value later. That really deserves its
own JIRA. Probably we could use {{Short.MIN_VALUE}} or 0 for that. There are
no shortage of reserved values, after all-- we send 32 bits over the wire but
only have 15 bits in a positive java short.
bq. Any reason why the edit log loader is no longer using the unprotected
functions? It should be safe to skip the checks, which makes edit log replaying
faster. If you do want to go with this, we should get rid of the unprotected
functions where possible / update the javadoc.
That must have leaked in when I ported this from 5096. Will fix.
> add 'replication' field to PathBasedCacheDirective
> --------------------------------------------------
>
> Key: HDFS-5358
> URL: https://issues.apache.org/jira/browse/HDFS-5358
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: namenode
> Affects Versions: HDFS-4949
> Reporter: Colin Patrick McCabe
> Assignee: Colin Patrick McCabe
> Attachments: HDFS-5358-caching.001.patch
>
>
> Add a 'replication' field to PathBasedCacheDirective, so that administrators
> can configure how many cached replicas of a block the cluster should try to
> maintain.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
