[
https://issues.apache.org/jira/browse/BOOKKEEPER-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13242269#comment-13242269
]
Sijie Guo commented on BOOKKEEPER-126:
--------------------------------------
> One corner case, if this re-write operation is failed in all the ledger
> dirs?, probably forced to choose another bookie and form a new ensemble?
maybe. a simple way is to choose a bookie to replicate all entries of the
ensemble contains the corrupted/missing.
{quote}
Say, entries 0-100 ledger metadata mapping is
0 (A, B, C)
50(B, C, D)
End Ledger:100
{quote}
as your example, 30-39 is corrupted, B is in the corn case as you stated, it
forced to choose another bookie E. E replicates the entries between 0~50
belongs to B. And replace (A, B, C) to (A, E, C), as what BookKeeperAdmin does.
> Secondly, for an opened/in-recovery ledger, how about the idea to check all
> the brothers and if no read success corresponding to x entry, will consider
> (x - 1) as the last entry. Packets in flight will be considered in the next
> pass, is it ok?
basically seems ok.
> EntryLogger doesn't detect when one of it's logfiles is corrupt
> ---------------------------------------------------------------
>
> Key: BOOKKEEPER-126
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-126
> Project: Bookkeeper
> Issue Type: Bug
> Reporter: Ivan Kelly
> Priority: Blocker
> Fix For: 4.1.0
>
>
> If an entry log is corrupt, the bookie will ignore any entries past the
> corruption. Quorum writes stops this being a problem at the moment, but we
> should detect corruptions like this and rereplicate if necessary.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
