[
https://issues.apache.org/jira/browse/KUDU-1508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15357849#comment-15357849
]
Adar Dembo commented on KUDU-1508:
----------------------------------
bq. b) Try to avoid multi-level extent trees- if we limit the number of blocks
per container to a smaller number (say 300) then it's quite unlikely to meet
this issue. It's not a sure thing (the system could have arbitrary amounts of
fragmentation) but it is easy to implement and probably would make the issue
rare enough to not be a problem.
While attractive, this will push up our open file handle footprint, which the
log block manager was specifically designed to avoid.
bq. d) Avoid hole punching - we could spend the time to build a block manager
implementation that doesn't rely on hole punching. This is likely a lot of work.
FWIW, we've discussed implementing compaction algorithm for the log block
manager for the purpose of reducing the number of open files. We now know that,
because full containers are never reused, we gradually end up with more and
more containers with a small number of blocks. Compacting groups of containers
into one, or compacting individual containers and reusing them would help. Plus
it'd open the door for using the log block manager on platforms that lack hole
punching such as older Linux kernels and macOS, plus with odd filesystems
(ecryptfs comes to mind).
Relatedly, I've been wondering whether the log block manager with hole punching
is net positive for the system. Sure, hole punching is fast, but if the end
result is a highly fragmented filesystem, that increases overhead as well as
(for spinning disks) the number of seeks. I wonder whether the I/O hit of
compaction (which we could bound, as we do for rowset compaction) would be
tolerable if it resulted in less fs fragmentation.
> 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)
