[ https://issues.apache.org/jira/browse/HDFS-3672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Wang updated HDFS-3672: ------------------------------ Attachment: hdfs-3672-1.patch First hack at this. I still want to add some more tests, but I think the design is about right. This essentially provides the same API as {{DFS#getFileBlockLocations}}, except it returns a subclass of {{BlockLocation}}, {{HdfsBlockLocation}}, which has an additional array of {{byte}}s which is an opaque identifier that specifies on which disk on a datanode the block resides. Currently, this ID is mapped to the index of the HDFS data directory containing the block file (e.g. /data/1, /data/2). This can thus change across reboots/config changes, and clients need to be prepared to requery anyway since blocks do move around as part of normal operation. I'd like to perhaps split the new {{DFS#getFileHdfsBlockLocations}} function into a call to {{DFS#getFileBlockLocations}} to do the NN query to get block locations, and then pass these to some other call ({{DFS#getDiskIds}}?), since this would let you do multiple calls to {{DFS#getFileBlockLocations}} and then do one series of RPCs to the datanodes. But, I need to figure out how to change the {{BlockLocation[]}} back into a {{LocatedBlock[]}}. It might also be nice to do the DN RPCs in parallel, since right now it's serial setup, query, teardown for each DN. > Expose disk-location information for blocks to enable better scheduling > ----------------------------------------------------------------------- > > Key: HDFS-3672 > URL: https://issues.apache.org/jira/browse/HDFS-3672 > Project: Hadoop HDFS > Issue Type: Improvement > Affects Versions: 2.0.0-alpha > Reporter: Andrew Wang > Assignee: Andrew Wang > Attachments: hdfs-3672-1.patch > > > Currently, HDFS exposes on which datanodes a block resides, which allows > clients to make scheduling decisions for locality and load balancing. > Extending this to also expose on which disk on a datanode a block resides > would enable even better scheduling, on a per-disk rather than coarse > per-datanode basis. > This API would likely look similar to Filesystem#getFileBlockLocations, but > also involve a series of RPCs to the responsible datanodes to determine disk > ids. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira