[
https://issues.apache.org/jira/browse/BOOKKEEPER-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506136#comment-13506136
]
Sijie Guo commented on BOOKKEEPER-249:
--------------------------------------
{quote}
Let me give an example to illustrate. Say a bookie stores fragments for ledgers
L1,L5,L6 and a client deletes L1 and L5. When it runs a gc cycle, it deletes L1
and L5 and writes to znode '/ledgers/deleted/Bi/Largest' the value L5.
Eventually, another client deletes L6, the bookie deletes L6 and sets the data
of '/ledgers/deleted/Bi/Largest' to L6. While checking the entries that it has
stored, Bi finds that it has entries for a ledger with id smaller than 6, say
L5, then it is safe to delete the entries.
{quote}
I don't think it was correct. since you could not guarantee the ledgers are
created in bookie in ledger id's order.
take you example:
1) at time T, we had L1, L5, L6 in a bookie. L1 and L5 is deleted.
2) a gc cycle is coming. L1 and L5 are deleted and 'Largest' znode is updated
to L5.
3) client of L2 is writing entries to this bookie now. L2 is created in this
bookie to stored its fragments.
4) next gc cycle is coming. this bookie would delete L2 even L2 hasn't been
deleted.
If I didn't understand your idea correctly, please correct me.
> Revisit garbage collection algorithm in Bookie server
> -----------------------------------------------------
>
> Key: BOOKKEEPER-249
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-249
> Project: Bookkeeper
> Issue Type: Improvement
> Components: bookkeeper-server
> Reporter: Sijie Guo
> Fix For: 4.2.0
>
> Attachments: gc_revisit.pdf
>
>
> Per discussion in BOOKKEEPER-181, it would be better to revisit garbage
> collection algorithm in bookie server. so create a subtask to focus on it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
