[
https://issues.apache.org/jira/browse/KUDU-1857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adar Dembo updated KUDU-1857:
-----------------------------
Attachment: test.c
Here's a prototype that uses the FIEMAP ioctl to print the base/bounds of all
extents in a file. I can imagine loading them into a data structure (interval
tree? sorted set?) and comparing it with the base/bounds of all dead blocks as
part of the repunchening.
> Retry LBM hole punching on crash
> --------------------------------
>
> Key: KUDU-1857
> URL: https://issues.apache.org/jira/browse/KUDU-1857
> Project: Kudu
> Issue Type: Bug
> Components: fs
> Reporter: Adar Dembo
> Attachments: test.c
>
>
> Given the LBM design, it's possible for block deletion to be committed via a
> metadata write, but for the subsequent hole punch to fail, or for the server
> to crash in between. As such, we should provide a mechanism to
> "re-hole-punch" deleted blocks. This could be dumb and hole punch every dead
> block in the container, or it could be smart and use the [FIEMAP
> ioctl|https://www.kernel.org/doc/Documentation/filesystems/fiemap.txt] to
> figure out which dead blocks have live extents and surgically punch them.
> Separately, this should be runnable at startup, and perhaps as part of a
> general filesystem checker in the CLI tool.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
