Hi Roy,
(a) In your last email, I am sure you meant => "... submitting read
requests to fetch "any" (instead of all) the 'k' chunk (out of k+m-x
surviving chunks) ?
Do you have any optimization in place to decide which data-nodes will
be part of those "k" ?
Answer:-
I hope you know
Hi Rakesh,
Thanks for sharing your thoughts and updates.
(a) In your last email, I am sure you meant => "... submitting read
requests to fetch "any" (instead of all) the 'k' chunk (out of k+m-x
surviving chunks) ?
Do you have any optimization in place to decide which data-nodes will be
part of
I'm adding one more point to the above. In my previous mail reply, I've
explained the striped block reconstruction task which will be triggered by
the Namenode on identifying a missing/bad block. Similarly, in case of hdfs
client read failure, currently hdfs client internally submitting read
Hi Roy,
Thanks for the interest in hdfs erasure coding feature and helping us in
making the feature more attractive to the users by sharing performance
improvement ideas.
Presently, the reconstruction work has been implemented in a centralized
manner in which the reconstruction task will be
Greetings!
We are evaluating erasure coding on HDFS to reduce storage cost.
However, the degraded read latency seems like a crucial bottleneck for our
system.
After exploring some strategies for alleviating the pain of degraded read
latency,
I found a "tree-like recovery" technique might be
