From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxim Patlasov Subject: Re: dm thin: How to shrink think pool device? Date: Wed, 18 Mar 2015 18:42:44 -0700 Message-ID: <550A2994.5000601@parallels.com> References: <20150319005144.GA18305@redhat.com> Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150319005144.GA18305@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Mike Snitzer Cc: dm-devel@redhat.com List-Id: dm-devel.ids On 03/18/2015 05:51 PM, Mike Snitzer wrote: > On Wed, Mar 18 2015 at 7:46pm -0400, > Maxim Patlasov wrote: > >> Hi, >> >> It seems that a "trim" pool message was planned long time ago, but never >> implemented. Could someone update about current status of that? The >> question came from the following use-case: >> >> Suppose we have a thin pool on top of LVM volume group. The group comprises >> of several storage drives. Now I need to (physically) remove one of them. >> The intention is to use pvmove and vgreduce, but obviously thin pool must >> be requested to shrink itself at first. > We only support growing the pool. If a drive used by the pool goes > missing then thin_repair will need to fix things. Do you think a feature allowing to shrink pool data device on-line smoothly will be useful (w.r.t all code complications needed to relocate data blocks inside dm-thin while handling i/o at the same time)? > >> Btw, Documentation/device-mapper/thin-provisioning.txt still has a leftover >> about it: >> >>> If you wish to reduce the size of your thin device and potentially >>> regain some space then send the 'trim' message to the pool. > I'll remove that stale documentation (commit 5ec02084f6 should've done > that). > > The 'trim' message was never about reducing pool space. The usage for > the trim message (sent to the pool device) was: > trim > > It was to reduce the size of the thin volume; don't think it was ever > wired up because it wasn't needed. Hm... "dmset load " seems to do exactly that. But, yes, it has nothing to do with reclaiming storage space back to the system. Thanks, Maxim