Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Basically that's what we have agreed in meeting - since we don't know yet how to handle different sector-sized PVs.
And a short fix could be to not allow that to happen on creating time.
But still there are already users having that VGs already created - so lvm2 can't just say such VG is invalid
and disable access to it...
So I'd probably see something similar we did for 'mirrorlog' -
add lvm.conf option to disable creation - that is respected on vgcreate time
Interesting, I asked about this here few weeks ago:
https://www.redhat.com/archives/linux-lvm/2019-February/msg00002.html
Based on the info in this bug, it looks like RHV should care about the
only the logical block size when extending or creating a VG.
David, Zdenek, what do you think?
Here's an initial, lightly-tested solution to the VG-consistency part. It does not address the issue of checking that a given LV is used with a consistent sector size. Perhaps if a user overrides the VG consistency check, it should be their responsibility to ensure LVs are consistent.
https://sourceware.org/git/?p=lvm2.git;a=commit;h=dd6ff9e3a75801fc5c6166aa0983fa8df098e91a
vgcreate/vgextend: check for inconsistent logical block sizes
When creating or extending a VG, check if the PVs have
inconsisent logical block sizes (value from BLKSSZGET ioctl).
If so, return an error. The error can be changed to a warning,
allowing the command to proceed with the mixed values, by
setting lvm.conf allow_mixed_logical_block_sizes=1.
pushed to master branch:
https://sourceware.org/git/?p=lvm2.git;a=commit;h=0404539edb25e4a9d3456bb3e6b402aa2767af6b
I can push to stable if this bug gets a rhel7 ack.
commit 0404539edb25e4a9d3456bb3e6b402aa2767af6b
Author: David Teigland <teigland>
Date: Thu Aug 1 10:06:47 2019 -0500
vgcreate/vgextend: restrict PVs with mixed block sizes
Avoid having PVs with different logical block sizes in the same VG.
This prevents LVs from having mixed block sizes, which can produce
file system errors.
The new config setting devices/allow_mixed_block_sizes (default 0)
can be changed to 1 to return to the unrestricted mode.
[root@null-01 ~]# blockdev --getss --getpbsz /dev/sdh
4096
2097152
[root@null-01 ~]# blockdev --getss --getpbsz /dev/loop0
512
512
[root@null-01 ~]# vgcreate mix /dev/sdh /dev/loop0
Devices have inconsistent logical block sizes (4096 and 512).
See lvm.conf allow_mixed_block_sizes.
[root@null-01 ~]# vgcreate --config devices/allow_mixed_block_sizes=1 mix /dev/loop0 /dev/sdh
Volume group "mix" successfully created with system ID one
[root@null-01 ~]# vgcreate mix /dev/sdh
Volume group "mix" successfully created with system ID one
[root@null-01 ~]# vgextend mix /dev/loop0
Devices have inconsistent logical block sizes (4096 and 512).
[root@null-01 ~]# vgextend --config devices/allow_mixed_block_sizes=1 mix /dev/loop0
Volume group "mix" successfully extended
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2020:1129
Description of problem: lvm should not allow extending an LV with a PV of different sector size than existing PVs making up the LV, since the FS on the LV does not mount once LVM adds in the new PV and extends the LV. How reproducible: Steps to Reproduce: ** Device: sdc (using the device with default sector size of 512) # blockdev --report /dev/sdc RO RA SSZ BSZ StartSec Size Device rw 8192 512 4096 0 1073741824 /dev/sdc ** LVM is created with the default sector size of 512. # blockdev --report /dev/mapper/testvg-testlv RO RA SSZ BSZ StartSec Size Device rw 8192 512 4096 0 1069547520 /dev/mapper/testvg-testlv ** The filesystem will also pick up 512 sector size. # mkfs.xfs /dev/mapper/testvg-testlv meta-data=/dev/mapper/testvg-testlv isize=512 agcount=4, agsize=65280 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=0, sparse=0 data = bsize=4096 blocks=261120, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal log bsize=4096 blocks=855, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 ** Now we will mount it # xfs_info /test meta-data=/dev/mapper/testvg-testlv isize=512 agcount=4, agsize=65280 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=0 spinodes=0 data = bsize=4096 blocks=261120, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal bsize=4096 blocks=855, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 ** Let's extend it with a PV with a sector size of 4096: #modprobe scsi_debug sector_size=4096 dev_size_mb=512 # fdisk -l /dev/sdd Disk /dev/sdd: 536 MB, 536870912 bytes, 131072 sectors Units = sectors of 1 * 4096 = 4096 bytes <============== Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 262144 bytes # blockdev --report /dev/sdd RO RA SSZ BSZ StartSec Size Device rw 8192 4096 4096 0 536870912 /dev/sdd # vgextend testvg /dev/sdd Physical volume "/dev/sdd" successfully created Volume group "testvg" successfully extended # lvextend -l +100%FREE /dev/mapper/testvg-testlv Size of logical volume testvg/testlv changed from 1020.00 MiB (255 extents) to 1.49 GiB (382 extents). Logical volume testlv successfully resized. # umount /test # mount /dev/mapper/testvg-testlv /test mount: mount /dev/mapper/testvg-testlv on /test failed: Function not implemented <=========== # dmesg | grep -i dm-2 [ 477.517515] XFS (dm-2): Unmounting Filesystem [ 486.905933] XFS (dm-2): device supports 4096 byte sectors (not 512) <============ The sector size of the lv is now 4096. # blockdev --report /dev/mapper/testvg-testlv RO RA SSZ BSZ StartSec Size Device rw 8192 4096 4096 0 1602224128 /dev/mapper/testvg-testlv Expected results: LVM should fail the lvextend if sector size is different to existing PV's Additional info: Discussed with Zdenek during LVM meeting in Brno