hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Wang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-12222) Add EC information to BlockLocation
Date Wed, 06 Sep 2017 00:23:02 GMT

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

Andrew Wang commented on HDFS-12222:

Hi Huafeng, thanks for working on this! A few review comments:

* Please fix checkstyles
* Sorry I missed this from your last comment: I thought we didn't need the new getECBlockLocation
method since normal users don't need to know about parity blocks. Can we remove DistributedFileSystem#getECBlockLocation
and DFSClient#getECBlockLocation and the ECBlockLocation class?
* Looks like some places where a user can get a BlockLocation will still include parity blocks,
like getFileBlockLocation. Could you also check the rest of the FileSystem API? We should
add test coverage for these APIs too: getFileBlockLocation, listFiles, listLocatedStatus,
* Also need to do the same changes for Hdfs.java for the FileContext API
* Need javadoc / comments in HdfsLocatedFileStatus and wherever else we modify to explain
the intent. It'd also be great to have an example of the expected format of BlockLocation[]
for a replicated vs. EC file.
* Could you verify that fsck -files -blocks -locations still returns parity blocks? We should
add a unit test for this if there isn't one.
* Also, could you add tests with a files of different sizes, e.g. bigger than one block group?
It NPEs right now for me when I call listLocatedStatus in TestWriteReadStripe#testFileMoreThanABlockGroup1.

> Add EC information to BlockLocation
> -----------------------------------
>                 Key: HDFS-12222
>                 URL: https://issues.apache.org/jira/browse/HDFS-12222
>             Project: Hadoop HDFS
>          Issue Type: Bug
>    Affects Versions: 3.0.0-alpha1
>            Reporter: Andrew Wang
>            Assignee: Huafeng Wang
>              Labels: hdfs-ec-3.0-nice-to-have
>         Attachments: HDFS-12222.001.patch, HDFS-12222.002.patch, HDFS-12222.003.patch
> HDFS applications query block location information to compute splits. One example of
this is FileInputFormat:
> https://github.com/apache/hadoop/blob/d4015f8628dd973c7433639451a9acc3e741d2a2/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/java/org/apache/hadoop/mapred/FileInputFormat.java#L346
> You see bits of code like this that calculate offsets as follows:
> {noformat}
>     long bytesInThisBlock = blkLocations[startIndex].getOffset() + 
>                           blkLocations[startIndex].getLength() - offset;
> {noformat}
> EC confuses this since the block locations include parity block locations as well, which
are not part of the logical file length. This messes up the offset calculation and thus topology/caching
information too.
> Applications can figure out what's a parity block by reading the EC policy and then parsing
the schema, but it'd be a lot better if we exposed this more generically in BlockLocation

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org

View raw message