[
https://issues.apache.org/jira/browse/HDFS-17535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17854008#comment-17854008
]
ruiliang commented on HDFS-17535:
---------------------------------
[https://github.com/liangrui1988/hadoop-client-op/blob/main/src/main/java/com/yy/bigdata/orc/OpenFileLine.java]
After studying for a long time, a bad block recovery method has been realized.
Two bad blocks (rs-3-1024) need to exclude datanode read the orc file for 10
times, and then check whether the orc is legitimate. The recovery program is as
follows, with changes to the source code, and the relevant jar is in the lib/
directory.
It would be best if a community official provided this feature.
> I have confirmed the EC corrupt file, can this corrupt file be restored?
> ------------------------------------------------------------------------
>
> Key: HDFS-17535
> URL: https://issues.apache.org/jira/browse/HDFS-17535
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: ec, hdfs
> Affects Versions: 3.1.0
> Reporter: ruiliang
> Priority: Blocker
>
> I learned that EC does have a major bug with file corrupt
> https://issues.apache.org/jira/browse/HDFS-15759
> 1：I have confirmed the EC corrupt file, can this corrupt file be restored?
> Have important data that is causing us production data loss issues? Is
> there a way to recover
> corrupt;/file;corrupt block groups \{blk_-xx} zeroParityBlockGroups
> \{blk_-xx[blk_-xx]}
> 2：https://github.com/apache/orc/issues/1939 I was wondering if cherry picked
> your current code (GitHub pull request #2869), Can I skip patches related to
> HDFS-14768,HDFS-15186, and HDFS-15240?
> hdfs version 3.1.0
> thank you
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
