[
https://issues.apache.org/jira/browse/HDFS-5378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799640#comment-13799640
]
Andrew Wang commented on HDFS-5378:
-----------------------------------
Looks mostly good, just a few things:
* Need to fixup some compile errors in TestFsDatasetCache
* Based on the actual contents of {{StorageReport}} it seems okay to just cram
everything in there even though some things aren't per-storage. I'd just do the
same fields as for disk: capacity, used, remaining, block pool used.
* I don't think we actually track per-blockpool cache usage, so need to add
that. This is one of the things I thought of related to federation.
> In CacheReport, don't send genstamp and length on the wire
> ----------------------------------------------------------
>
> Key: HDFS-5378
> URL: https://issues.apache.org/jira/browse/HDFS-5378
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: datanode
> Affects Versions: HDFS-4949
> Reporter: Colin Patrick McCabe
> Assignee: Colin Patrick McCabe
> Attachments: HDFS-5378-caching.001.patch,
> HDFS-5378-caching.002.patch, HDFS-5378-caching.003.patch
>
>
> As discussed in HDFS-5096, we don't need genstamp and block length when
> processing cache reports. So let's not send them over the wire (it increases
> the size of cache reports to 3x what it could be).
> Also, we should report the caching statistics alongside the normal DN stats
> in {{StorageReport}}. There's no reason for them to be separate. Since the
> new fields will be optional and default to 0, there will be no extra overhead
> in the non-caching case.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
