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.
Cause: scrub command fails when directed at symlink to block device
Consequence: scrub is not able to scrub a multipath device or a LVM logical volume by directing the scrub command at the /dev/mapper/* device, as this kind of path correspond to a symbolic link.
Fix: Patch was introduced to check if the path received is a symbolic link and, if so, resolve it to the appropriate destination
Result: After fix, scrub can be used to scrub paths where specified device is a symbolic link.
Description of problem:
scrub command fails when directed at symlink to block device
Version-Release number of selected component (if applicable):
scrub-2.5.2-7.el7
How reproducible:
Every time
Steps to Reproduce:
36001405fff91eb31f8e4b14936db06d2 dm-31 LIO-ORG ,ram2
size=10G features='4 queue_if_no_path retain_attached_hw_handler queue_mode mq' hwhandler='1 alua' wp=rw
`-+- policy='round-robin 0' prio=0 status=active
|- 1:0:1:27 sdae 65:224 active undef running
|- 2:0:1:27 sdja 8:320 active undef running
|- 1:0:2:27 sdsx 8:592 active undef running
`- 2:0:2:27 sdlh 67:496 active undef running
[root@root ~]# ls -lah /dev/mapper/36001405fff91eb31f8e4b14936db06d2
lrwxrwxrwx 1 root root 8 Jan 25 15:53 /dev/mapper/36001405fff91eb31f8e4b14936db06d2 -> ../dm-31
# scrub -b 8M -fp dod /dev/mapper/36001405fff91eb31f8e4b14936db06d2
scrub: using DoD 5220.22-M patterns
scrub: warning: /dev/mapper/36001405fff91eb31f8e4b14936db06d2 is zero length <===== failure
# scrub -b 8M -fp dod /dev/dm-31 <===== success if directed toward underlying device
scrub: using DoD 5220.22-M patterns
scrub: please verify that device size below is correct!
scrub: scrubbing /dev/dm-31 10737418240 bytes (~10GB)
scrub: random |................................................|
scrub: 0x00 |................................................|
scrub: 0xff |................................................|
scrub: verify |................................................|
I was able to workaround the issue by specifying the size manually.
# src/scrub -s 10G -b 8M -fp dod /dev/mapper/36001405fff91eb31f8e4b14936db06d2
scrub: using DoD 5220.22-M patterns
scrub: scrubbing /dev/mapper/36001405fff91eb31f8e4b14936db06d2 10737418240 bytes (~10GB)
scrub: random |................................................|
scrub: 0x00 |................................................|
scrub: 0xff |................................................|
scrub: verify |................................................|
Expected results:
We should be able to scrub a multipath device or a LVM logical volume by directing the scrub command at the /dev/mapper/* device.
Additional Info:
The command works as expected in RHEL6. I've reproduced the issue on RHEL7 and RHEL8.
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 (scrub 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-2021:4328