From: Spelic <spelic@shiftmail.org>
To: dm-devel@redhat.com, thornber@redhat.com
Subject: Re: [NOTES] thinp zeroing
Date: Wed, 22 Feb 2012 17:30:04 +0100 [thread overview]
Message-ID: <4F45180C.8030801@shiftmail.org> (raw)
In-Reply-To: <20120222141442.GA28145@ubuntu>
On 02/22/12 15:14, Joe Thornber wrote:
> * Requirements
>
> There are two distinct requirements for zeroing applicable to the
> thin-provisioning target:
>
> - Avoid data leaks (DATA_LEAK)
>
> * Implementing DATA_LEAK
>
>
> * Implementing ERASE
>
> ** Erase on deallocation
>
>
> ** Erasing from userland.
>
> ** Crash recovery
>
> ** Discards
>
>
Hello
thanks for all your hard work regarding thinp
I was thinking: why don't you implement a bitmap that takes care of
emulating the discard functionality?
This would take care of all your issues above, and also be great for a
lot of use cases even outside thinp (*).
Every read would first hit the bitmap; if the bitmap says that the
region has been discarded, thinp would return zeroes to the requestor.
When a discard comes, you first set the bits in the
discard-emulation-bitmap, and then also pass the discard to layers
below. Passing the discard below has no user-visible effects (because
discard is already implemented in thinp) however it is still
advantageous to pass it to lower layers because there might be SSDs
below thinp which can benefit from the discard.
I suggest a bitmap of 4kbytes / bit, and then if a discard comes that is
not 4K aligned (that would be a mistake of the above layers, at least a
"performance" mistake), you set the bitmaps only for the bits which are
completely covered by the discard, and then you are left with at most
two misaligned edges one at the beginning and one at the end of the
discard region, and for those you will need to write zeroes to the
layers below. So in the worst case you need to set a few bits and then
perform two small writes of zeroes, but in most cases you just set a few
bits.
(*) remember that most MD Raid levels do not pass discards below, so we
-raid users- cannot really see zeroes where discard has been triggered.
That's a problem when we want to backup a virtual machine disk image (DM
volume) from the outside: non-zeroes don't compress well; it's like we
backup deleted files everytime.
next prev parent reply other threads:[~2012-02-22 16:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-22 14:14 [NOTES] thinp zeroing Joe Thornber
2012-02-22 14:25 ` [PATCH] [dm-thin] experimental erase-log patch Joe Thornber
2012-02-22 16:30 ` Spelic [this message]
2012-02-22 18:04 ` [NOTES] thinp zeroing Zdenek Kabelac
2012-02-23 15:43 ` Joe Thornber
2012-02-23 2:49 ` Mike Snitzer
2012-02-23 15:47 ` Joe Thornber
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=4F45180C.8030801@shiftmail.org \
--to=spelic@shiftmail.org \
--cc=dm-devel@redhat.com \
--cc=thornber@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.