linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@redhat.com>
To: vaLentin chernoZemski <valentin@siteground.com>
Cc: linux-lvm@redhat.com
Subject: Re: [linux-lvm] lvremove does not pass discards if volume is part of thin pool
Date: Mon, 10 Aug 2015 13:49:00 -0400	[thread overview]
Message-ID: <20150810174900.GC22719@redhat.com> (raw)
In-Reply-To: <55C86723.4000707@siteground.com>

On Mon, Aug 10 2015 at  4:56am -0400,
vaLentin chernoZemski <valentin@siteground.com> wrote:

> Hi folks,
> 
> I am experiencing issues with LVM thin pool and discards that should
> be passed down during lvremove but they are not.
> 
> Setup looks like this:
> 
> Sparse file -> Loop device -> PV -> VG -> Thin Pool -> LV
> 
> If we mount -o discard LV and fill it with data which is later
> deleted sparse file shrinks back ~ to the original size.
> 
> However if we directly lvremove LV, the sparse file does not shrink
> back its size so we are forced to use fallocate (which is slow).
> 
> According to the docs lvremove should issue discards to the
> underlying device but it appears that this is not the case if LV is
> part of thin pool
> 
> lsblk -D shows DISC-ZERO as 0 for tpool tmeta and tdata devices and
> all their childs which is strange.
> 
> [root@testbed ~]# lsblk -D | grep ^NAME ; lsblk -D | grep -A8
> $group-thingroup_tmeta
> NAME                                                       DISC-ALN
> DISC-GRAN DISC-MAX DISC-ZERO
> |-testgroup-thingroup_tmeta (dm-33)                               0
> 4K       4G         1
> | `-testgroup-thingroup-tpool (dm-35)                             0
> 64K      64K         0
> |   |-testgroup-thingroup (dm-36)                                 0
> 64K      64K         0
> |   `-testgroup-testvol (dm-37)                                   0
> 64K      64K         0
> `-testgroup-thingroup_tdata (dm-34)                               0
> 4K       4G         1
>   `-testgroup-thingroup-tpool (dm-35)                             0
> 64K      64K         0
>     |-testgroup-thingroup (dm-36)                                 0
> 64K      64K         0
>     `-testgroup-testvol (dm-37)                                   0
> 64K      64K         0
> 
> Kernel version we are using is 3.12.x.
> 
> Linux 3.2 - discard support for loop devices - http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=dfaa2ef68e80c378e610e3c8c536f1c239e8d3ef
> 
> Linux 3.4 - discard support for thin pool - http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=104655fd4dcebd50068ef30253a001da72e3a081

Plese verify your kernel has this commit:
19fa1a6756e ("dm thin: fix discard support to a previously shared block")

But it doesn't look like you're using snapshots so this may not matter.

> /etc/lvm/lvm.conf is configured as follows
> 
>     issue_discards = 1
>     thin_pool_discards = "passdown"
> 
> Here is a sample script that demonstrate the issue. Note the output
> after the second lvremove where size of "loop-block-device-file"
> remains unchanged even volume is removed.
> 
> set -e
> file=/root/testfile
> group=testgroup
> thingroup=thingroup
> volume_name=testvol
> volume_size=200M
> 
> grep -i disca /etc/lvm/lvm.conf  | grep -v \#
> rpm -qa | grep lvm2
> uname -r
> 
> [[ -f ${file} ]] && unlink ${file}
> truncate ${file} --size 10G
> loopdev=$(losetup -f --show ${file})
> pvcreate --metadatasize 1M ${loopdev}
> vgcreate ${group} -s 1MiB ${loopdev}
> pe_size=$(vgdisplay "/dev/${group}" | grep 'PE Size' | awk '{print $3}')
> thin_size=$(echo "$(vgdisplay "/dev/${group}" | grep 'Free  PE' |
> awk '{print $5}')*${pe_size}-180" | bc -l)
> lvcreate --ignoreactivationskip -Z n -L ${thin_size}m -T
> "/dev/${group}/${thingroup}"
> lvcreate --ignoreactivationskip -V${volume_size} -T
> "${group}/${thingroup}" -n "${volume_name}"
> mkfs.ext4 /dev/$group/$volume_name
> sync && du -hs $file
> lvs $group
> lsblk -D | grep ^NAME ; lsblk -D | grep -A8 $group-thingroup_tmeta
> sync && du -hs $file
> mkdir -p /mnt/tmp/
> mount -o discard /dev/$group/$volume_name /mnt/tmp/
> dd if=/dev/zero of=/mnt/tmp/fill_file count=100 bs=1M
> sync && du -hs $file
> umount /mnt/tmp/
> sync && du -hs $file
> mount -o discard /dev/$group/$volume_name /mnt/tmp/
> rm -f /mnt/tmp/fill_file
> sync && du -hs $file
> umount /mnt/tmp/
> sync && du -hs $file
> lvremove -f /dev/$group/$volume_name
> lvcreate --ignoreactivationskip -V${volume_size} -T
> "${group}/${thingroup}" -n "${volume_name}"
> mkfs.ext4 /dev/$group/$volume_name
> lvs $group
> lsblk -D | grep ^NAME ; lsblk -D | grep -A8 $group-thingroup_tmeta
> sync && du -hs $file
> mkdir -p /mnt/tmp/
> mount -o discard /dev/$group/$volume_name /mnt/tmp/
> dd if=/dev/zero of=/mnt/tmp/fill_file count=100 bs=1M
> sync && du -hs $file
> umount /mnt/tmp/
> sync && du -hs $file
> lvremove -f $group/$volume_name
> echo "==== AFTER THIS LVREMOVE size should shrink but it does not ==="

If you do have the patch I referenced above then something else is going
on.  You should probably run with: lvremove -vvvv to see if lvm is
actually issuing a discard.  Or you could use blktrace to see if the
thin device you're removing is actually receiving a discard.

  reply	other threads:[~2015-08-10 17:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-10  8:56 [linux-lvm] lvremove does not pass discards if volume is part of thin pool vaLentin chernoZemski
2015-08-10 17:49 ` Mike Snitzer [this message]
2015-08-11  8:07   ` vaLentin chernoZemski
2015-08-11 14:35     ` Mike Snitzer
2015-08-11 14:56       ` vaLentin chernoZemski
2015-08-12  7:46       ` Peter Rajnoha
2015-08-12  7:57         ` Peter Rajnoha
2015-08-19 10:40       ` vaLentin chernoZemski
2016-01-22 17:18         ` Tomas Janousek
2016-01-26 17:03           ` Tomas Janousek

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=20150810174900.GC22719@redhat.com \
    --to=snitzer@redhat.com \
    --cc=linux-lvm@redhat.com \
    --cc=valentin@siteground.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).