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:
The new xfsprogs(xfsprogs-3.2.0-0.3.alpha2.el7) in RHEL-7 has removed "xfs_check" command, and use "xfs_repair -n" to instead it. But the fsadm command still use it as "XFS_CHECK=xfs_check".
If I use the fsadm to check xfs filesystem, I will get:
/usr/sbin/fsadm: line 124: xfs_check: command not found
Version-Release number of selected component (if applicable):
[root@hp-dl380eg8-03 ~]# rpm -qa|grep lvm
lvm2-libs-2.02.103-6.el7.x86_64
lvm2-2.02.103-6.el7.x86_64
[root@hp-dl380eg8-03 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.0 Beta (Maipo)
[root@hp-dl380eg8-03 ~]# uname -r
3.10.0-64.el7.x86_64
How reproducible:
Just use it to check xfs filesystem
Additional info:
I try to make this change, then it worked(check xfs filesystem) OK.
--- fsadm 2014-01-12 06:50:19.056111693 -0500
+++ fsadm.new 2014-01-12 06:47:13.066535527 -0500
@@ -53,7 +53,7 @@ GREP=grep
READLINK=readlink
READLINK_E="-e"
FSCK=fsck
-XFS_CHECK=xfs_check
+XFS_CHECK=xfs_repair
# user may override lvm location by setting LVM_BINARY
LVM=${LVM_BINARY:-lvm}
@@ -430,7 +430,7 @@ check() {
esac
case "$FSTYPE" in
- "xfs") dry "$XFS_CHECK" "$VOLUME" ;;
+ "xfs") dry "$XFS_CHECK" -n "$VOLUME" ;;
*) # check if executed from interactive shell environment
case "$-" in
*i*) dry "$FSCK" $YES $FORCE "$VOLUME" ;;
But I think it's not a good patch. Just for test.
We apply patches upstream, and upstream needs to remain compatible with older versions.
Is your change guaranteed to work with all older versions?
Or do we need an 'either/or' choice between the two?
And if so, is that a run-time or configure-time decision?
My rawhide still contains xfs_check in the package:
xfsprogs-3.2.0-0.3.alpha2.fc21.x86_64
With this notice in the front of script:
==
echo "xfs_check is deprecated and scheduled for removal in June 2014."
echo "Please use xfs_repair -n <dev> instead."
==
I assume we may switch the code that assings XFS_CHECK like
$(which xfs_check) -> when empty assign to "xfs_repair -n"
fsadm tool has been updated in upstream repository:
http://www.redhat.com/archives/lvm-devel/2014-January/msg00029.html
It's not a perfect replacement but IMHO should be working properly, unless some xfs skilled developer has a better idea.
Currently the patch always passes in -o force_geometry, since the xfs_repair tool seems to be puzzled with xfs filesystem with just only 1 allocation group.
I think this is fine for now, FWIW, but I would actually just switch to xfs_repair unconditionally because it is faster and scales much better. I understand agk's concern that:
> We apply patches upstream, and upstream needs to remain compatible with older versions.
but xfs_repair has been around since, well, forever. No need to change this for RHEL7 (xfs_check is *gone* in RHEL7) but maybe something to consider for upstream.
Thanks,
-Eric
As for the single allocation group, that only happens for *extremely* small filesystems, but I guess it needs to be covered somehow.
If you have questions about this kind of thing in the future, please reach out to the xfs list, and we can be sure that we've got optimal behavior.
Thanks,
-Eric
This request was resolved in Red Hat Enterprise Linux 7.0.
Contact your manager or support representative in case you have further questions about the request.
Description of problem: The new xfsprogs(xfsprogs-3.2.0-0.3.alpha2.el7) in RHEL-7 has removed "xfs_check" command, and use "xfs_repair -n" to instead it. But the fsadm command still use it as "XFS_CHECK=xfs_check". If I use the fsadm to check xfs filesystem, I will get: /usr/sbin/fsadm: line 124: xfs_check: command not found Version-Release number of selected component (if applicable): [root@hp-dl380eg8-03 ~]# rpm -qa|grep lvm lvm2-libs-2.02.103-6.el7.x86_64 lvm2-2.02.103-6.el7.x86_64 [root@hp-dl380eg8-03 ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.0 Beta (Maipo) [root@hp-dl380eg8-03 ~]# uname -r 3.10.0-64.el7.x86_64 How reproducible: Just use it to check xfs filesystem Additional info: I try to make this change, then it worked(check xfs filesystem) OK. --- fsadm 2014-01-12 06:50:19.056111693 -0500 +++ fsadm.new 2014-01-12 06:47:13.066535527 -0500 @@ -53,7 +53,7 @@ GREP=grep READLINK=readlink READLINK_E="-e" FSCK=fsck -XFS_CHECK=xfs_check +XFS_CHECK=xfs_repair # user may override lvm location by setting LVM_BINARY LVM=${LVM_BINARY:-lvm} @@ -430,7 +430,7 @@ check() { esac case "$FSTYPE" in - "xfs") dry "$XFS_CHECK" "$VOLUME" ;; + "xfs") dry "$XFS_CHECK" -n "$VOLUME" ;; *) # check if executed from interactive shell environment case "$-" in *i*) dry "$FSCK" $YES $FORCE "$VOLUME" ;; But I think it's not a good patch. Just for test.