#3640 PR `closed`: Unsupported option xfs sparse¶

Labels: enhancement, bug, won't fix / can't fix / obsolete

sebastian-koehler opened issue at 2026-09-18 05:19:¶

Type: Bug Fix
Impact: High — rear recover currently fails to (re)create the root filesystem at all on any target whose mkfs.xfs predates -i sparse= support (e.g. RHEL 7.9 / xfsprogs 4.5.0), and the failure isn't a clean abort: the disk-layout-recreation menu just keeps re-running the same failing command forever, which looks like a hang rather than an error.
Reference to related issue (URL): None filed — found during live end-to-end BACKUP=NBU recovery testing, not tracked as a separate issue.
How was this pull request tested?

Reproduced on a real RHEL 7.9 NetBackup client (xfsprogs/mkfs.xfs 4.5.0). rear recover consistently failed at the disk-layout-recreation step with:
```
mkfs.xfs -f -m uuid=... -i sparse=0 ... /dev/mapper/rhel-root
unknown option -i sparse=0
```
Confirmed via the captured rear recover log and lsblk/xfs_info output that xfs_info on this xfsprogs version already reports a spinodes attribute, but the paired mkfs.xfs binary doesn't accept -i sparse= at filesystem-creation time — so xfs_parse() was generating an option the local mkfs.xfs can't handle. Validated the fix with bash -n, then deployed it into the live booted rescue environment on the same RHEL 7.9 host for a rear recover retest.
Description of the changes in this pull request:

Adds mkfs_xfs_supports_sparse_inodes() to usr/share/rear/lib/filesystems-functions.sh, which probes the target's own mkfs.xfs usage output (run without a device argument) to check whether it actually supports the -i sparse= suboption, rather than assuming a fixed xfsprogs version cutoff. xfs_parse() now skips emitting -i sparse=... when the probe says it's unsupported, so filesystem recreation falls back to mkfs.xfs defaults for that option instead of failing outright.

codacy-production commented at 2026-09-18 05:20:¶

Not up to standards ⛔¶

🔴 Issues 14 high · 9 medium

>
> > **Alerts:** > ⚠ 23 issues (≤ 0 issues of at least minor severity) > > **Results:** > `23` new issues > > > > > > > > > > > > > > > > > > >

Category	Results
BestPractice	`8` medium
ErrorProne	`1` medium `14` high

> > [View in > Codacy](https://app.codacy.com/gh/rear/rear/pull-requests/3640/issues) >

_{NEW Get contextual insights on your PRs based on Codacy's
metrics, along with PR and Jira context, without leaving GitHub. Enable
AI
reviewer}
_{TIP This summary will be updated as you push new changes.}

jsmeix commented at 2026-09-18 07:15:¶

@sebastian-koehler
the changes in this pull request contain too much.

It seems all changes from your other pull request
https://github.com/rear/rear/pull/3638
are included in this pull request again.

This pull request should only contain the changes
which belong to what this pull request is about which
are - as far as I see - only the changes in the file
usr/share/rear/lib/filesystems-functions.sh‎
but I did not check the details if perhaps also
some parts of the changes in other files also
belong to what this pull request is about.

jsmeix commented at 2026-10-02 10:41:¶

This one is superseded by
https://github.com/rear/rear/pull/3647

[Export of Github issue for rear/rear.]