linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
* [linux-lvm] lvreduce ignores --test for implicit BLKDISCARD?
@ 2017-12-06 16:09 Carl-Daniel Hailfinger
  2017-12-06 16:38 ` Carl-Daniel Hailfinger
  0 siblings, 1 reply; 2+ messages in thread
From: Carl-Daniel Hailfinger @ 2017-12-06 16:09 UTC (permalink / raw)
  To: linux-lvm

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [linux-lvm] lvreduce ignores --test for implicit BLKDISCARD?
  2017-12-06 16:09 [linux-lvm] lvreduce ignores --test for implicit BLKDISCARD? Carl-Daniel Hailfinger
@ 2017-12-06 16:38 ` Carl-Daniel Hailfinger
  0 siblings, 0 replies; 2+ messages in thread
From: Carl-Daniel Hailfinger @ 2017-12-06 16:38 UTC (permalink / raw)
  To: linux-lvm

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/
>

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2017-12-06 16:38 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 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).