[
https://issues.apache.org/jira/browse/KUDU-1508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adar Dembo resolved KUDU-1508.
------------------------------
Resolution: Fixed
Spoke offline with JD and Todd. We've decided to make the following the
project's official position:
# Because of the block limits in place, it's pretty rare to encounter this
corruption in the wild. In our test cluster, only 21 containers out of ~600,000
were corrupted.
# We believe the corruption is harmless and can be repaired as part of a
regular fsck.
# It's specific to ext4, so switching to xfs will solve the problem.
# Red Hat has fixed the underlying issue in el6.9 and has also backported the
fix to the kernel in el6.8.
So I'm going to leave this FIXED for the time being, but please reopen if
you're experiencing this and the above recommendations do not work for you!
> Log block manager triggers ext4 hole punching bug in el6
> --------------------------------------------------------
>
> Key: KUDU-1508
> URL: https://issues.apache.org/jira/browse/KUDU-1508
> Project: Kudu
> Issue Type: Bug
> Components: fs
> Affects Versions: 0.9.0
> Reporter: Todd Lipcon
> Assignee: Adar Dembo
> Priority: Blocker
> Fix For: 1.2.0
>
> Attachments: debugfs.txt, e9f83e4acef3405f99d01914317351ce.metadata,
> filefrag.txt, pbc_dump.txt, replay_container.py
>
>
> I've experienced many times that when I reboot an el6 node that was running
> Kudu tservers, fsck reports issues like:
> data6 contains a file system with errors, check forced.
> data6: Interior extent node level 0 of inode 5259348:
> Logical start 154699 does not match logical start 2623046 at next level.
> After some investigation, I've determined that this is due to an ext4 kernel
> bug: https://patchwork.ozlabs.org/patch/206123/
> Details in a comment to follow.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
