[
https://issues.apache.org/jira/browse/BOOKKEEPER-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13932063#comment-13932063
]
Sijie Guo commented on BOOKKEEPER-716:
--------------------------------------
{quote}
That said, I think this change can be made without breaking BC. Instead of
having a [mask][len][bytes...] which is 8bytes min, you could have
[len][ledgerid][entryid] where ledgerid = -1, which is 20bytes min, but which
will be simply discarded when the scanner gets it on recovery, because the
ledger doesn't exist anymore. This would be backwards compat.
{quote}
your solution would introduce a bit problematic, if the ledger id generator
generates a ledger id with -1. and if you read the patch, this change also
extends the journal head size to align with sector size. that's the reason why
bumping the version.
and for the option, I don't mind adding the option if you feel strong on it.
but I still don't understand how could an option help. if there is problem on
this change, you might still hit it when you enable the option and you couldn't
get back, no? I am kind of thinking the right thing is to do bucket testing:
upgrade a few nodes, stabilize it. if anything bad happened, take those few
nodes out and run bookie recover and rollback to 4.2.0.
> padding writes for bookie journal
> ---------------------------------
>
> Key: BOOKKEEPER-716
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-716
> Project: Bookkeeper
> Issue Type: Sub-task
> Components: bookkeeper-server
> Reporter: Sijie Guo
> Assignee: Sijie Guo
> Fix For: 4.3.0
>
> Attachments: BOOKKEEPER-716.diff, BOOKKEEPER-716_715.diff
>
>
> it would be better to pad journal writes to align sector size, which to avoid
> second syncing corrupt an already synced sector/page.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
