[ https://issues.apache.org/jira/browse/HADOOP-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525549 ]
Hadoop QA commented on HADOOP-1838: ----------------------------------- +1 http://issues.apache.org/jira/secure/attachment/12365210/blockSizeZero.patch applied and successfully tested against trunk revision r573383. Test results: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/698/testReport/ Console output: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/698/console > Files created with an pre-0.15 gets blocksize as zero, causing performance > degradation > -------------------------------------------------------------------------------------- > > Key: HADOOP-1838 > URL: https://issues.apache.org/jira/browse/HADOOP-1838 > Project: Hadoop > Issue Type: Bug > Components: dfs > Affects Versions: 0.15.0 > Reporter: dhruba borthakur > Assignee: dhruba borthakur > Priority: Blocker > Fix For: 0.15.0 > > Attachments: blockSizeZero.patch > > > HADOOP-1656 introduced the support for storing block size persistently as > inode metadata. Previously, if the file has only one block then it was not > possible to accurately determine the blocksize that the application has > requested at file-creation time. > The upgrade of an older layout to the new layout kept the blocksize as zero > for single-block files that were upgraded to the new layout. This was done to > indicate the DFS really does not know the "true" blocksize of this file. This > caused map-reduce to determine that a split is 1 byte in length! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.