[
https://issues.apache.org/jira/browse/KUDU-1508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Todd Lipcon updated KUDU-1508:
------------------------------
Attachment: e9f83e4acef3405f99d01914317351ce.metadata
For reference, here's the metadata corresponding to one of the block containers
that hit this issue (I used debugfs to map the broken inode back to a path).
The container had 7971 blocks, of which 7602 are now deleted, so definitely
seems plausible that it had >340 extents at one point, though currently it has
only 226.
> 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
> Priority: Blocker
> Attachments: e9f83e4acef3405f99d01914317351ce.metadata
>
>
> 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.4#6332)
