All of lore.kernel.org
 help / color / mirror / Atom feed
From: Douglas McClendon <dmc.fedora@filteredperception.org>
To: device-mapper development <dm-devel@redhat.com>
Subject: Re: Re: trimmable dm-snapshot?
Date: Thu, 22 Oct 2009 16:16:32 -0600	[thread overview]
Message-ID: <4AE0D9C0.9050801@filteredperception.org> (raw)
In-Reply-To: <4AE0D02A.7070806@filteredperception.org>

Douglas McClendon wrote:
> Mike Snitzer wrote:
>> On Wed, Oct 21 2009 at 11:05pm -0400,
>> Douglas McClendon <dmc.fedora@filteredperception.org> wrote:
>>
>>> Has anyone looked into the idea of dm-snapshots responding
>>> appropriately to trims from filesystems?
>>>
>>> I.e. the efficiency problem of a dm-snapshotted ext filesystem
>>> having files created and then deleted?  I.e. in such a scenario,
>>> resources in the cow device end up taken that could be freed if the
>>> dm layer could efficiently respond to trim notifications by
>>> discarding any useless exceptions?
>>>
>>> I've been poking around pondering whether an offline quick hack
>>> might be possible with libext2fs and enough knowledge of the on-disk
>>> persistent snapshot format.  I.e. just walk the exception chunks in
>>> the cow device, use libext2fs (sufficient? easiest way?) to
>>> determine whether all the fsblocks/sectors the chunk contains are
>>> all currently unneeded, and if so reclaiming that space (possibly by
>>> relocating the last exception. I'm still a distance from truly
>>> grokking the on-disk format along with the rest of the dm-snapshot
>>> and exception-store code).
>>>
>>> Does any of this make sense?  Been looked at?  Seem like a
>>> reasonable avenue to pursue?
>>
>> The snapshot must faithfully maintain a copy of the origin's data
>> relative to a particular point in time.  You can't use changes to the
>> origin (trim or any other change) to delete the exceptions that a
>> snapshot is already maintaining.  That would invalidate the whole intent
>> of the snapshot.
> 
> I wasn't asking about trimmable dm-snapshot-origin devices, only 
> trimmable[1] dm-snapshot devices.
> 
> Thinking about snapshot-origin devices, what you say is a valid reason 
> why such optimization is not remotely easy (or feasible at all).

Actually, a way you might accomplish a corresponding optimization with 
dm-snapshot-origin would be this-

- At filesystem mount time, a sequence of initial discard requests for 
all unused portions of the filesystem is passed down to the block/dm 
layer.  Then, the dm-snapshot-origin code would know to never create an 
exception for a chunk that is a subset of those regions.

-dmc

  reply	other threads:[~2009-10-22 22:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-22  3:05 trimmable dm-snapshot? Douglas McClendon
2009-10-22 14:20 ` Mike Snitzer
2009-10-22 21:35   ` Douglas McClendon
2009-10-22 22:16     ` Douglas McClendon [this message]
2009-10-23  1:02       ` Douglas McClendon

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=4AE0D9C0.9050801@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.