All of lore.kernel.org
 help / color / mirror / Atom feed
From: Douglas McClendon <dmc.fedora@filteredperception.org>
To: dm-devel@redhat.com
Subject: Re: Discard support for dm-snap
Date: Thu, 02 Sep 2010 13:21:05 -0500	[thread overview]
Message-ID: <4C7FEB11.8090903@filteredperception.org> (raw)
In-Reply-To: <4C7F5AE2.9020908@suse.de>

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

  parent reply	other threads:[~2010-09-02 18:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-02  8:05 Discard support for dm-snap Hannes Reinecke
2010-09-02 14:14 ` Mike Snitzer
2010-09-02 18:21 ` Douglas McClendon [this message]
2010-09-03  5:45   ` Hannes Reinecke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C7FEB11.8090903@filteredperception.org \
    --to=dmc.fedora@filteredperception.org \
    --cc=dm-devel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.