[
https://issues.apache.org/jira/browse/KUDU-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17190713#comment-17190713
]
ASF subversion and git services commented on KUDU-2260:
-------------------------------------------------------
Commit ae776c12895b1f2a60b95749d7a8cb31d0e841ad in kudu's branch
refs/heads/master from Attila Bukor
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=ae776c1 ]
Fix a Google+ link
When fixing KUDU-2260 a Google+ link was added for additional context in
a comment. As Google+ was shut down since then, this link is now dead.
Tried replacing it with a Wayback Machine link, but it doesn't seem to
load anymore either. Unfortunately I couldn't find a more formal
documentation for this, but at least Alexey managed to find an
explanation on Hacker News (there also happens to be a link to the
Google+ post in that thread). Hopefully it stays online for far longer
than Google+.
Change-Id: I7e10e49b08428079d3134e9291328e4508822ecf
Reviewed-on: http://gerrit.cloudera.org:8080/16279
Tested-by: Attila Bukor <[email protected]>
Reviewed-by: Grant Henke <[email protected]>
> Log block manager should handle null bytes in metadata on crash
> ---------------------------------------------------------------
>
> Key: KUDU-2260
> URL: https://issues.apache.org/jira/browse/KUDU-2260
> Project: Kudu
> Issue Type: Bug
> Components: fs
> Reporter: Mike Percy
> Assignee: William Berkeley
> Priority: Major
> Fix For: 1.8.0
>
>
> The log block manager currently may leave null bytes at the end of the
> metadata log file if there is a system crash in the middle of a write. The
> log block manager should detect null bytes at the end of a metadata entry on
> startup and potentially truncate the entry or close the container.
> Currently, it prints an error along the following lines:
> {code}
> F0111 09:30:27.327011 28843 tablet_server_main.cc:64] Check failed: _s.ok()
> Bad status: Corruption: Failed to load FS layout: Could not read records from
> container /data/3/kudu/data/f70391c7c6084e08bbae7448518e0b5e: Data length
> checksum does not match: Incorrect checksum in file
> /data/3/kudu/data/f70391c7c6084e08bbae7448518e0b5e.metadata at offset 372533:
> Checksum does not match. Expected: 0. Actual: 1323915147
> {code}
> At the time of writing, the workaround for this issue is to truncate the
> affected file at the start of the incomplete entry in the file. While this
> may leave orphaned blocks, this should be safe because if the metadata entry
> was never successfully written then it should not have been considered
> durable, either.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)