linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
To: linux-lvm@redhat.com
Subject: Re: [linux-lvm] lvreduce ignores --test for implicit BLKDISCARD?
Date: Wed, 6 Dec 2017 17:38:30 +0100	[thread overview]
Message-ID: <3198217f-e968-4b64-c27a-f37e67e45335@gmx.net> (raw)
In-Reply-To: <970a1f8b-fe0f-c078-2062-8436d19df1a7@gmx.net>

Hi,

just a quick followup: If I don't run lvreduce --test before the actual
reduce, everything works fine:

# lvreduce --verbose --size 40G --resizefs /dev/mapper/kubuntu--vg-root
    Finding volume group kubuntu-vg
    Executing: fsadm --verbose check /dev/kubuntu-vg/root
fsadm: "ext4" filesystem found on "/dev/mapper/kubuntu--vg-root"
fsadm: Executing fsck -p /dev/mapper/kubuntu--vg-root
fsck from util-linux 2.27.1
/dev/mapper/kubuntu--vg-root: clean, 211747/30212096 files, 3291346/120836096 blocks
    Executing: fsadm --verbose resize /dev/kubuntu-vg/root 41943040K
fsadm: "ext4" filesystem found on "/dev/mapper/kubuntu--vg-root"
fsadm: Device "/dev/mapper/kubuntu--vg-root" size is 494944649216 bytes
fsadm: Parsing tune2fs -l "/dev/mapper/kubuntu--vg-root"
fsadm: Resizing filesystem on device "/dev/mapper/kubuntu--vg-root" to 42949672960 bytes (120836096 -> 10485760 blocks of 4096 bytes)
fsadm: Executing resize2fs /dev/mapper/kubuntu--vg-root 10485760
resize2fs 1.42.13 (17-May-2015)
Resizing the filesystem on /dev/mapper/kubuntu--vg-root to 10485760 (4k) blocks.
The filesystem on /dev/mapper/kubuntu--vg-root is now 10485760 (4k) blocks long.

    Archiving volume group "kubuntu-vg" metadata (seqno 3).
    Reducing logical volume kubuntu-vg/root to 40.00 GiB
  Size of logical volume kubuntu-vg/root changed from 460.95 GiB (118004 extents) to 40.00 GiB (10240 extents).
    Loading kubuntu--vg-root table (253:1)
    Suspending kubuntu--vg-root (253:1) with device flush
    Resuming kubuntu--vg-root (253:1)
    Creating volume group backup "/etc/lvm/backup/kubuntu-vg" (seqno 4).
  Logical volume root successfully resized.


Obviously, this new run was done after reinstalling the corrupted system.


Regards,
Carl-Daniel


On 06.12.2017 17:09, Carl-Daniel Hailfinger wrote:
> Hi,
>
> I just lost some of the contents of a file system by running
>
> lvreduce --test --verbose --size 40G --resizefs /dev/mapper/kubuntu-root
>
> AFAICS this was caused by BLKDISCARD being issued despite --test. No LV
> in the affected VG was mounted at the time of data loss.
>
> Don't worry, this was a test system directly after installation, it
> didn't have any important data on it.
>
> This is a Kubuntu 16.04.3 installation on a 500 GB SSD, during setup
> "whole disk with encrypted LVM" was chosen. The only non-default setting
> was enabling discard support manually in dm-crypt. The exact setup is as
> follows:
>
>
> 500 GB Samsung SSD (/dev/sda)
> sda1: 512.00 MiB FAT32 (EFI System partition)
> sda2: 488.00 MiB ext2 (/boot partition)
> sda3: 464.78 GiB LUKS (encrypted container for LVM PV, BLKDISCARD support enabled)
>
> # pvdisplay 
>   --- Physical volume ---
>   PV Name               /dev/mapper/sda3_crypt
>   VG Name               kubuntu-vg
>   PV Size               464.78 GiB / not usable 4.00 MiB
>   Allocatable           yes (but full)
>   PE Size               4.00 MiB
>   Total PE              118983
>   Free PE               0
>   Allocated PE          118983
>   PV UUID               [...]
>    
> # vgdisplay 
>   --- Volume group ---
>   VG Name               kubuntu-vg
>   System ID             
>   Format                lvm2
>   Metadata Areas        1
>   Metadata Sequence No  3
>   VG Access             read/write
>   VG Status             resizable
>   MAX LV                0
>   Cur LV                2
>   Open LV               0
>   Max PV                0
>   Cur PV                1
>   Act PV                1
>   VG Size               464.78 GiB
>   PE Size               4.00 MiB
>   Total PE              118983
>   Alloc PE / Size       118983 / 464.78 GiB
>   Free  PE / Size       0 / 0   
>   VG UUID               [...]
>    
> # lvdisplay 
>   --- Logical volume ---
>   LV Path                /dev/kubuntu-vg/root
>   LV Name                root
>   VG Name                kubuntu-vg
>   LV UUID                [...]
>   LV Write Access        read/write
>   LV Creation host, time kubuntu, 2017-12-06 15:58:07 +0100
>   LV Status              available
>   # open                 0
>   LV Size                460.95 GiB
>   Current LE             118004
>   Segments               1
>   Allocation             inherit
>   Read ahead sectors     auto
>   - currently set to     256
>   Block device           253:1
>    
>   --- Logical volume ---
>   LV Path                /dev/kubuntu-vg/swap_1
>   LV Name                swap_1
>   VG Name                kubuntu-vg
>   LV UUID                [...]
>   LV Write Access        read/write
>   LV Creation host, time kubuntu, 2017-12-06 15:58:08 +0100
>   LV Status              available
>   # open                 0
>   LV Size                3.82 GiB
>   Current LE             979
>   Segments               1
>   Allocation             inherit
>   Read ahead sectors     auto
>   - currently set to     256
>   Block device           253:2
>
>
> # lvreduce --version
> LVM version:     2.02.133(2) (2015-10-30)
> Library version: 1.02.110 (2015-10-30)
> Driver version:  4.35.0
> # resize2fs --version
> resize2fs 1.42.13 (17-May-2015)
> # cryptsetup --version
> cryptsetup 1.6.6
> # uname -r
> 4.10.0-28-generic
>
> Steps to reproduce:
> # cryptsetup --allow-discards luksOpen /dev/sda3 sda3_crypt
> Enter passphrase for /dev/sda3: 
> # vgchange -a y
>   2 logical volume(s) in volume group "kubuntu-vg" now active
> # lvreduce --test --verbose --size 40G --resizefs /dev/mapper/kubuntu--vg-root 
>   TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
>     Finding volume group kubuntu-vg
>     Executing: fsadm --dry-run --verbose check /dev/kubuntu-vg/root
> fsadm: "ext4" filesystem found on "/dev/mapper/kubuntu--vg-root"
> fsadm: Dry execution fsck -p /dev/mapper/kubuntu--vg-root
>     Executing: fsadm --dry-run --verbose resize /dev/kubuntu-vg/root 41943040K
> fsadm: "ext4" filesystem found on "/dev/mapper/kubuntu--vg-root"
> fsadm: Device "/dev/mapper/kubuntu--vg-root" size is 494944649216 bytes
> fsadm: Parsing tune2fs -l "/dev/mapper/kubuntu--vg-root"
> fsadm: Resizing filesystem on device "/dev/mapper/kubuntu--vg-root" to 42949672960 bytes (120836096 -> 10485760 blocks of 4096 bytes)
> fsadm: Dry execution resize2fs /dev/mapper/kubuntu--vg-root 10485760
>     Test mode: Skipping archiving of volume group.
>     Reducing logical volume kubuntu-vg/root to 40.00 GiB
>   Size of logical volume kubuntu-vg/root changed from 460.95 GiB (118004 extents) to 40.00 GiB (10240 extents).
>     Test mode: Skipping backup of volume group.
>   Logical volume root successfully resized.
>     Test mode: Wiping internal cache
>     Wiping internal VG cache
> # lvreduce --verbose --size 40G --resizefs /dev/mapper/kubuntu--vg-root 
>     Finding volume group kubuntu-vg
>     Executing: fsadm --verbose check /dev/kubuntu-vg/root
> fsadm: "ext4" filesystem found on "/dev/mapper/kubuntu--vg-root"
> fsadm: Executing fsck -p /dev/mapper/kubuntu--vg-root
> fsck from util-linux 2.27.1
> /dev/mapper/kubuntu--vg-root: Superblock has an invalid journal (inode 8).
> CLEARED.
> *** ext3 journal has been deleted - filesystem is now ext2 only ***
>
> /dev/mapper/kubuntu--vg-root: Superblock has_journal flag is clear, but a journal is present.
> CLEARED.
> /dev/mapper/kubuntu--vg-root: Journal inode is not in use, but contains data.  CLEARED.
> /dev/mapper/kubuntu--vg-root: Inode 3801089 is in use, but has dtime set.  FIXED.
> /dev/mapper/kubuntu--vg-root: Inode 3801089 has a extra size (8780) which is invalid
> FIXED.
> /dev/mapper/kubuntu--vg-root: Inode 3801089 has compression flag set on filesystem without compression support.  
>
> /dev/mapper/kubuntu--vg-root: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
>         (i.e., without -a or -p options)
>     fsadm failed: 4
>   Filesystem check failed.
> #
>
>
> Compare this to a test run where BLKDISCARD support in the LUKS volume is disabled:
> # lvreduce --test --verbose --size 40G --resizefs /dev/mapper/kubuntu--vg-root 
>   TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
>     Finding volume group kubuntu-vg
>     Executing: fsadm --dry-run --verbose check /dev/kubuntu-vg/root
> fsadm: "ext4" filesystem found on "/dev/mapper/kubuntu--vg-root"
> fsadm: Dry execution fsck -p /dev/mapper/kubuntu--vg-root
>     Executing: fsadm --dry-run --verbose resize /dev/kubuntu-vg/root 41943040K
> fsadm: "ext4" filesystem found on "/dev/mapper/kubuntu--vg-root"
> fsadm: Device "/dev/mapper/kubuntu--vg-root" size is 494944649216 bytes
> fsadm: Parsing tune2fs -l "/dev/mapper/kubuntu--vg-root"
> fsadm: Resizing filesystem on device "/dev/mapper/kubuntu--vg-root" to 42949672960 bytes (120836096 -> 10485760 blocks of 4096 bytes)
> fsadm: Dry execution resize2fs /dev/mapper/kubuntu--vg-root 10485760
>     Test mode: Skipping archiving of volume group.
>     Reducing logical volume kubuntu-vg/root to 40.00 GiB
>   /dev/mapper/sda3_crypt: BLKDISCARD ioctl at offset 42950721536 size 451994976256 failed: Operation not supported.
>   Size of logical volume kubuntu-vg/root changed from 460.95 GiB (118004 extents) to 40.00 GiB (10240 extents).
>     Test mode: Skipping backup of volume group.
>   Logical volume root successfully resized.
>     Test mode: Wiping internal cache
>     Wiping internal VG cache
>
>
> The message "BLKDISCARD [...] failed" in the non-fatal test run seems
> to imply that BLKDISCARD is issued even if --test is specified.
> I do not know whether this is the fault of lvreduce, fsadm or resize2fs.
>
> Any information about the possible reasons for this problem as well as
> potential bugfixes would be appreciated.
>
> Regards,
> Carl-Daniel
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>

      reply	other threads:[~2017-12-06 16:38 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-06 16:09 [linux-lvm] lvreduce ignores --test for implicit BLKDISCARD? Carl-Daniel Hailfinger
2017-12-06 16:38 ` Carl-Daniel Hailfinger [this message]

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=3198217f-e968-4b64-c27a-f37e67e45335@gmx.net \
    --to=c-d.hailfinger.devel.2006@gmx.net \
    --cc=linux-lvm@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 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).