[
https://issues.apache.org/jira/browse/KUDU-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Todd Lipcon updated KUDU-1793:
------------------------------
Resolution: Fixed
Fix Version/s: 1.2.0
Status: Resolved (was: In Review)
> When out of disk space, LBM can corrupt data files
> --------------------------------------------------
>
> Key: KUDU-1793
> URL: https://issues.apache.org/jira/browse/KUDU-1793
> Project: Kudu
> Issue Type: Bug
> Affects Versions: 1.1.0
> Reporter: Adar Dembo
> Assignee: Adar Dembo
> Priority: Blocker
> Fix For: 1.2.0
>
>
> The log block manager can corrupt a container data file when the following
> conditions are met:
> # A data directory runs out of disk space.
> # The operation in question is a merge compaction (that is, the server does
> not crash).
> # The data directory eventually empties somewhat, allowing the server to
> recover.
> When all of these conditions are met, the changes introduced by commit
> abea8c6 (released in 1.1.0) may cause the container's bookkeeping to become
> somewhat inconsistent. Specifically, if the data dir has enough free space
> such that the container is able to append some data belonging to a new block
> but not finalize that block, an unexpected "hole" may be added to the
> container.
> When the server is restarted, the container's bookkeeping doesn't account for
> this hole, leading to data being overwritten when a new block is appended to
> the container. Moreover, commit 4aacaf6 (not yet released) exacerbates the
> issue by causing the LBM to explicitly truncate the container at the wrong
> place during startup, yielding immediate data loss.
> This case was observed in an internal Cloudera cluster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
