ZFS "partially filled holes lose birth time"
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
zfs-linux (Debian) |
Fix Released
|
Unknown
|
|||
zfs-linux (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Note: This is different from Launchpad bug #1557151. This is another, similar, bug.
Bug description from Matt Ahrens at OpenZFS:
"If a ZFS object contains a hole at level one, and then a data block is
created at level 0 underneath that l1 block, l0 holes will be created.
However, these l0 holes do not have the birth time property set; as a
result, incremental sends will not send those holes.
Fix is to modify the dbuf_read code to fill in birth time data."
-- https:/
From pcd on IRC in #zfsonlinux:
"basically, what happens is this: if you zero out an entire l1 indirect
block's worth of data (several megabytes), we save space by storing that
entire indirect block as a single hole in an l2 indirect block with
birth time N. If you then modify some of the data under that, but not
all of it, when the l1 indirect block is filled back in with mostly
holes and some data blocks, the wholes will not have any"
Fixed in ZoL here:
https:/
This has *not* been merged into a ZoL release yet, nor the release branch.
This is a very unfortunate bug because the fix only helps you moving forward. A separate bug has been opened to propose a fix for that:
https:/
description: | updated |
Changed in zfs-linux (Debian): | |
status: | Unknown → New |
Changed in zfs-linux (Debian): | |
status: | New → Fix Committed |
Changed in zfs-linux (Debian): | |
status: | Fix Committed → Fix Released |
Changed in zfs-linux (Ubuntu): | |
status: | Confirmed → Fix Released |
Status changed to 'Confirmed' because the bug affects multiple users.