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.
Description of problem:
lvm has a couple of features planned for 8.3 (writecache and integrity) that need this upstream commit to check the fs block size:
commit cd129b7d2fecd5f2013512936de2db1bf244aa75
Author: Mikulas Patocka <mpatocka>
Date: Mon Sep 2 12:28:39 2019 +0200
blkid: retport block size of a filesystem
This patch extends libblkid, so that it reports filesystem block size.
When blkid returns a specific number in the BLOCK_SIZE attribute, it
guarantees that all the bios submitted by the filesystem are aligned on
this boundary.
We need this because when we want to enable dm-integrity or dm-writecache
on an existing filesystem, we need to know filesystem block size, so that
dm-integrity or dm-writecache is initialized with matching block size.
We could always use block size 512 for dm-integrity and dm-writecache, but
that would cause metadata overhead and performance degradation. On the
other hand, if we used block size 4096, it would fail if the filesystem
has smaller blocksize.
[kzak: - move vfat BLOCK_SIZE to probing function
- remove unwanted debug fprintf from ZFS prober]
Signed-off-by: Mikulas Patocka <mpatocka>
Signed-off-by: Karel Zak <kzak>
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
(In reply to David Teigland from comment #2)
> I'd like to find a way to test this with lvm, is there a build with this
> patch I can install on rhel8?
Not yet, I plan 8.3 build for the next week.
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 (util-linux bug fix and enhancement update), 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:4575
Description of problem: lvm has a couple of features planned for 8.3 (writecache and integrity) that need this upstream commit to check the fs block size: commit cd129b7d2fecd5f2013512936de2db1bf244aa75 Author: Mikulas Patocka <mpatocka> Date: Mon Sep 2 12:28:39 2019 +0200 blkid: retport block size of a filesystem This patch extends libblkid, so that it reports filesystem block size. When blkid returns a specific number in the BLOCK_SIZE attribute, it guarantees that all the bios submitted by the filesystem are aligned on this boundary. We need this because when we want to enable dm-integrity or dm-writecache on an existing filesystem, we need to know filesystem block size, so that dm-integrity or dm-writecache is initialized with matching block size. We could always use block size 512 for dm-integrity and dm-writecache, but that would cause metadata overhead and performance degradation. On the other hand, if we used block size 4096, it would fail if the filesystem has smaller blocksize. [kzak: - move vfat BLOCK_SIZE to probing function - remove unwanted debug fprintf from ZFS prober] Signed-off-by: Mikulas Patocka <mpatocka> Signed-off-by: Karel Zak <kzak> Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: