FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Device-mapper Development

 
 
LinkBack Thread Tools
 
Old 09-02-2010, 08:05 AM
Hannes Reinecke
 
Default Discard support for dm-snap

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)

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 09-02-2010, 02:14 PM
Mike Snitzer
 
Default Discard support for dm-snap

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

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 09-02-2010, 06:21 PM
Douglas McClendon
 
Default Discard support for dm-snap

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


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 09-03-2010, 05:45 AM
Hannes Reinecke
 
Default Discard support for dm-snap

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�g
GF: Markus Rex, HRB 16746 (AG N�g)

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 

Thread Tools




All times are GMT. The time now is 01:44 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org