[
https://issues.apache.org/jira/browse/HDFS-1111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12904359#action_12904359
]
Konstantin Shvachko commented on HDFS-1111:
-------------------------------------------
Dhruba. I'd be glad to discuss how to make corrupted blocks available to
RaidNode in a subsequent jira.
Currently the method in ClientProtocl lacks the functionality stated in this
jira, and does not conform to the design proposed by Sriram. So it has to be
replaced by another method or removed. As it is not used anywhere in the code
I'd prefer that it is removed from the protocol until the exact api is
developed. It looks like this effort should be coordinated with MAPREDUCE-2036
so that both RAID solutions could benefit from it.
Would you agree?
> getCorruptFiles() should give some hint that the list is not complete
> ---------------------------------------------------------------------
>
> Key: HDFS-1111
> URL: https://issues.apache.org/jira/browse/HDFS-1111
> Project: Hadoop HDFS
> Issue Type: New Feature
> Affects Versions: 0.22.0
> Reporter: Rodrigo Schmidt
> Assignee: Sriram Rao
> Fix For: 0.22.0
>
> Attachments: HADFS-1111.0.patch, HDFS-1111-y20.1.patch,
> HDFS-1111-y20.2.patch, HDFS-1111.trunk.patch
>
>
> If the list of corruptfiles returned by the namenode doesn't say anything if
> the number of corrupted files is larger than the call output limit (which
> means the list is not complete). There should be a way to hint incompleteness
> to clients.
> A simple hack would be to add an extra entry to the array returned with the
> value null. Clients could interpret this as a sign that there are other
> corrupt files in the system.
> We should also do some rephrasing of the fsck output to make it more
> confident when the list is not complete and less confident when the list is
> known to be incomplete.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
