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

[Joe Thornber <thornber@redhat.com>]

On Tue, May 01, 2012 at 02:53:22PM +0200, Spelic wrote:
> 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?

I'm planning to do replication via userland.  There's a new message
that allows userland to access a read-only copy of the metadata.  From
this, and using some intermediate snapshots we can work out what data
is changing and replicate it (asynchronously).

> The "HOLE" would mean "data comes from parent snapshot/device",
> while DATA is "data that has changed since the parent snapshot".

This sounds like the external snapshots feature that I just added.
See documentation in latest kernel.

> 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).

A great question.  If the discard exactly covers some dm-thin blocks,
then the mappings will be removed.  Any future io to that block will
trigger the block to be reprovisioned.  Depending whether you've set
the block zeroing flag in the pool, you are guaranteed to have zeroes
come out.

Any partial block discards will get passed down to the underlying data
device (assuming you've selected that option).  Any zeroing side
effects depend on the underlying device.

As for identifying empty blocks from userland: there is an inherant
race here.  What would you do with the info?

- Joe