[
https://issues.apache.org/jira/browse/KUDU-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15238152#comment-15238152
]
Todd Lipcon commented on KUDU-1414:
-----------------------------------
bq. It's possible that they were fsynced and then a couple of bytes along the
border of the last 2 entries were corrupted. Then Kudu was killed, resulting in
no footer. We would not detect the data loss.
But isn't this an extremely rare scenario? Typically an on-disk post-write
corruption would be a flipped bit (a single byte) which would only affect a
single entry. And the chances that such a thing would occur on the tail of a
file is also low. And then even if we incorrectly truncated the file and
started up, we'd get an error when trying to open the block, mark the tablet as
corrupt, and restore from another replica, because such an error wouldn't be
correlated across machines.
The more likely scenario for corruption towards the end of a file is a partial
write, which might be a string of zeros (eg one sector or 4k page) followed by
some real data. In that case, we do want to truncate it rather than fail
startup, no?
> Corrupting multiple log entries at the end of a WAL file may go undetected
> --------------------------------------------------------------------------
>
> Key: KUDU-1414
> URL: https://issues.apache.org/jira/browse/KUDU-1414
> Project: Kudu
> Issue Type: Bug
> Components: log
> Affects Versions: 0.8.0
> Reporter: Mike Percy
>
> While looking at KUDU-1377, I investigated how we are handling WAL truncation
> when corruption is detected. The way the code is written today, a trailing
> series of corrupt log entries are truncated with only a log warning message.
> I'll post a unit test demonstrating this behavior.
> One way to get around this is to ensure that we only accept zeros following a
> truncated record, instead of just bad records, in order to consider it a
> partially-written record that we can safely truncate. We would have to
> maintain this invariant when preallocating space and truncating partial
> records before continuing to write.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
