dm-thin f.req. : SEEK_DATA / SEEK_HOLE / SEEK_DISCARD

[Spelic <spelic@shiftmail.org>]

Dear dm-thin developers,
I thought that it would be immensely useful to have a SEEK_DATA / 
SEEK_HOLE implementation for dm-thin and/or even for the older non-thin 
snapshotting mechanism.
This would allow to implement a mechanism like the acclaimed "zfs send" 
with dm snapshots, i.e. cheaply replicate a thin snapshot remotely once 
the parent snapshot has been replicated already. Extremely useful imho.
Is there any plan to do that?
The "HOLE" would mean "data comes from parent snapshot/device", while 
DATA is "data that has changed since the parent snapshot". Discarded 
regions that were not discarded in the parent snapshot should preferably 
appear as zeroed DATA and not HOLE, or a new type SEEK_DISCARD because 
if you make it HOLE, you lose information (you lose: "such data region 
was meaningful in the parent snapshot but is not meaningful in the child 
snapshot", and this kind of information cannot be recovered later in any 
way) and you lose the property that reading those regions return zeroed 
data, which is a major problem for backups, see next paragraph.
Instead, if a discarded region returns zeroed DATA, not much information 
is lost because any long string of zeroes is interchangeable with a 
discard, i.e. you can detect zeroes and perform the discard afterwards. 
A new type SEEK_DISCARD could still be better.

Another question / feature request: I would like to know if reading an 
area of a thin device after a discard is guaranteed to return zeroes 
(and/or can be identified as empty from userspace via a seek_data / 
seek_hole or equivalent mechanism). This would be very important for 
backups, so to not get scarcely compressible garbage out of an old and 
now unused region.
If yes: how big should such discarded area be for that area to be seen 
from userspace as hole/zeroes: 512b, 4k, or 64m? E.g. a 512b discarded 
area surrounded by nondiscarded data will return zeroes on read?

Thank you
S.