You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Dan Burkert (JIRA)" <ji...@apache.org> on 2017/10/25 16:32:00 UTC
[jira] [Commented] (KUDU-1508) Log block manager triggers ext4 hole
punching bug in el6
[ https://issues.apache.org/jira/browse/KUDU-1508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16219011#comment-16219011 ]
Dan Burkert commented on KUDU-1508:
-----------------------------------
[~adar] there doesn't appear to be a commit 1a12d46 in the codebase. I think you meant [65695a30345913d69fec7ef777d990e549719e09|https://github.com/apache/kudu/commit/65695a30345913d69fec7ef777d990e549719e09]?
> 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.4.14#64029)