You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Adar Dembo (JIRA)" <ji...@apache.org> on 2017/05/02 21:12:04 UTC

[jira] [Updated] (KUDU-1857) Retry LBM hole punching on crash

     [ https://issues.apache.org/jira/browse/KUDU-1857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adar Dembo updated KUDU-1857:
-----------------------------
    Status: In Review  (was: In Progress)

> 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
>            Assignee: 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)