Discard support for dm-snap

Discard support for dm-snap

[Hannes Reinecke]

Hi all,

now that we've got discard support in the block layer, are there plans
to update dm-snap to actually implement discard?
Looks like a valid addendum here; we could be freeing up unused blocks
thus freeing up space.
Especially helpful when using dm-snap to create a sparse device;
cf
http://www.mjmwired.net/kernel/Documentation/device-mapper/zero.txt

Thoughts?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)

Re: Discard support for dm-snap

[Mike Snitzer]

On Thu, Sep 02 2010 at  4:05am -0400,
Hannes Reinecke <hare@suse.de> wrote:

> Hi all,
> 
> now that we've got discard support in the block layer, are there plans
> to update dm-snap to actually implement discard?
> Looks like a valid addendum here; we could be freeing up unused blocks
> thus freeing up space.
> Especially helpful when using dm-snap to create a sparse device;
> cf
> http://www.mjmwired.net/kernel/Documentation/device-mapper/zero.txt
> 
> Thoughts?

From https://www.redhat.com/archives/dm-devel/2010-July/msg00149.html

"The snapshot and crypt targets will not have discard support.

Snapshots must preserve any data that is deleted so the value of
discard is negligible.  Discard support for the origin target may be
considered in the future (could be especially useful if origin and COW
are different devices and origin is a thinly provisioned LUN)."

The snapshot target must always preserve changes (in the form of
exceptions in the COW store).  Even though you'd be removing files
through the snapshot device as far as the snapshot is concerned it must
track that change (relative to the origin).  Simply put: the current
snapshot store format doesn't easily allow for what you're asking for.

The new shared snapshot target that is in development may provide an
opportunity for adding more intelligence to account for this use-case.

Mikulas and/or Joe may have more insight here.

Mike

Re: Discard support for dm-snap

[Douglas McClendon]

On 09/02/2010 03:05 AM, Hannes Reinecke wrote:
> Hi all,
>
> now that we've got discard support in the block layer, are there plans
> to update dm-snap to actually implement discard?
> Looks like a valid addendum here; we could be freeing up unused blocks
> thus freeing up space.
> Especially helpful when using dm-snap to create a sparse device;
> cf
> http://www.mjmwired.net/kernel/Documentation/device-mapper/zero.txt
>
> Thoughts?

Here was my similar suggestion and the discussion with Mike that followed-

http://www.spinics.net/lists/dm-devel/msg11632.html

I still feel like there is a disconnect between my thinking and Mike's, 
as I think I have the same fundamental interest as you do Hannes.

I.e. a perfect example is a simple dm-snapshot used for a livecd root 
filesystem.  In that case, after boot, the user creates a new file in 
the rootfs, and that causes exception chunks (terminology?) to be 
created in the cow device of the dm-snapshot.  Then, at a later point, 
the user deletes that file.  It then seems 100% reasonable for the 
discard request to result in freeing the used resources in the cow 
device.  I see no semantic reason why that data need be kept around any 
more than it need be kept around on an SSD after a file is deleted.

Now, where I think the disconnect comes in, is that perhaps the majority 
use of snapshots in todays word is perhaps a snapshot-origin 
(terminology?) where the exception store (not quite a 'cow device'?) is 
not used to store the modified blocks, but instead, used to store the 
original blocks.  In _that_ case, things are different, perhaps more as 
Mike described them.

Now, I do understand that Mike is the person actually neck deep in all 
this code, so I could be completely misunderstanding the picture.  But 
I'm glad someone else also sees what I see here as far as potential 
benefit and use case.

-dmc

>
> Cheers,
>
> Hannes

Re: Discard support for dm-snap

[Hannes Reinecke]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 2157 bytes --]

On Thu, Sep 02, 2010 at 01:21:05PM -0500, Douglas McClendon wrote:
> On 09/02/2010 03:05 AM, Hannes Reinecke wrote:
>> Hi all,
>>
>> now that we've got discard support in the block layer, are there plans
>> to update dm-snap to actually implement discard?
>> Looks like a valid addendum here; we could be freeing up unused blocks
>> thus freeing up space.
>> Especially helpful when using dm-snap to create a sparse device;
>> cf
>> http://www.mjmwired.net/kernel/Documentation/device-mapper/zero.txt
>>
>> Thoughts?
>
> Here was my similar suggestion and the discussion with Mike that followed-
>
> http://www.spinics.net/lists/dm-devel/msg11632.html
>
> I still feel like there is a disconnect between my thinking and Mike's, as 
> I think I have the same fundamental interest as you do Hannes.
>
Yes and no. Snapshotting is similar but not identical to a sparse device.

> I.e. a perfect example is a simple dm-snapshot used for a livecd root 
> filesystem.  In that case, after boot, the user creates a new file in the 
> rootfs, and that causes exception chunks (terminology?) to be created in 
> the cow device of the dm-snapshot.  Then, at a later point, the user 
> deletes that file.  It then seems 100% reasonable for the discard request 
> to result in freeing the used resources in the cow device.  I see no 
> semantic reason why that data need be kept around any more than it need be 
> kept around on an SSD after a file is deleted.
>
It has to be for snapshotting. The main idea of snapshotting is the
possibility to do a rollback, ie that you can mount an earlier snapshot
instead of the current one and re-start from there.
This ability is lost if a later snapshot deletes blocks permanently;
these blocks would have to be removed from _all_ snapshots to really
free up space. But this would make rollback impossible.

Tempting as it may sound, I fear it's not going to work in general.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]