[jira] Commented: (HADOOP-731) Sometimes when a dfs file is accessed and one copy has a checksum error the I/O command fails, even if another copy is alright.

["Hadoop QA (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HADOOP-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467157 ] 

Hadoop QA commented on HADOOP-731:
----------------------------------

+1, because http://issues.apache.org/jira/secure/attachment/12349420/hadoop-731-7.patch applied and successfully tested against trunk revision r499156.

> Sometimes when a dfs file is accessed and one copy has a checksum error the I/O command fails, even if another copy is alright.
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HADOOP-731
>                 URL: https://issues.apache.org/jira/browse/HADOOP-731
>             Project: Hadoop
>          Issue Type: Bug
>          Components: dfs
>    Affects Versions: 0.7.2
>            Reporter: Dick King
>         Assigned To: Wendy Chien
>         Attachments: hadoop-731-7.patch
>
>
> for a particular file [alas, the file no longer exists -- I had to progress]  
>     $dfs -cp foo bar        
> and
>     $dfs -get foo local
> failed on a checksum error.  The dfs browser's download function retrieved the file, so either that function doesn't check, or more likely the download function got a different copy.
> When a checksum fails on one copy of a file that is redundantly stored, I would prefer that dfs try a different copy, mark the bad one as not existing [which should induce a fresh copy being made from one of the good copies eventually], and make the call continue to work and deliver bytes.
> Ideally, if all copies have checksum errors but it's possible to piece together a good copy I would like that to be done.
> -dk

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.