All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.