From: "Bryn M. Reeves" <bmr@redhat.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Cc: Mike Snitzer <snitzer@redhat.com>
Subject: Re: [linux-lvm] lvm2: zeroing free space
Date: Fri, 04 Feb 2011 16:37:14 +0000 [thread overview]
Message-ID: <4D4C2B3A.3010704@redhat.com> (raw)
In-Reply-To: <20110204155403.GD1535@redhat.com>
On 02/04/2011 03:54 PM, Mike Snitzer wrote:
> On Fri, Feb 04 2011 at 9:12am -0500,
> Bryn M. Reeves <bmr@redhat.com> wrote:
>
>> Hi Folks,
>>
>> Recently had a query from someone using an array supporting thin provisioning
>> with zero page reclaim[1].
>>
>> They wanted a method to write zeros to all the unallocated space in a VG to
>> trigger a reclaim of unused regions in the VG's PVs.
>>
>> My suggestion was to lvcreate a -l100%FREE LV named "filler" and overwrite it
>> from /dev/zero.
>>
>> It seems like this might something a lot of users want as this functionality
>> gets to be more common.
>>
>> I wondered if it could be worth adding a script to automate this or even an
>> option to vgchange (e.g. --zero-free-space)?
>>
>> Didn't have time to try putting anything together yet but it seems such a
>> feature could be useful.
>
> Do these HDS arrays also support discard? Would seem to me that issuing
> discards for the free space would be better (more standard) than writing
> zeros to accomplish the same.
>
> This variant would be: vgchange --discard-free-space
There are two variants of reclamation currently supported by external storage
products.
The WRITE_SAME/TRIM based explicit discard support is superior when the entire
storage stack supports it and I agree it would be good to support this mode of
reclaim too (superior in that you lose the zero-write overhead and associated
reclaim lag and can get better space utilisation since the host "knows" better
which blocks are unused).
Several vendors (at least HDS/EMC that I know of) also support an implicit
reclaim mode known as zero page/space reclaim in which the storage de-allocates
blocks that are overwritten with zeros.
I suppose the ideal solution would be to detect whether the storage supports one
or the other automatically but I don't know that there is a way to achieve this
right now (TRIM/WRITE_SAME possibly but I think the zero page stuff is entirely
transparent).
Regards,
Bryn.
next prev parent reply other threads:[~2011-02-04 16:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-04 14:12 [linux-lvm] lvm2: zeroing free space Bryn M. Reeves
2011-02-04 15:54 ` Mike Snitzer
2011-02-04 16:21 ` hansbkk
2011-02-04 16:37 ` Bryn M. Reeves [this message]
2011-02-04 20:02 ` Martin K. Petersen
2011-02-08 2:10 ` wayne.berthiaume
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=4D4C2B3A.3010704@redhat.com \
--to=bmr@redhat.com \
--cc=linux-lvm@redhat.com \
--cc=snitzer@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.