xfsprogs-4.16; scrubbing and files w/o /usr dependencies...

I was noticing in a newer version of xfsprogs that it puts some non-/usr-lib dependent files in /sbin, specifically fsck.mfs(shell), mkfs.xfs, xfs_repair xfs_scrub, and xfs_scrub_all.

What was the decider for putting these files in /sbin? The reason I ask is that the last one 'xfs_scrub_all' has a heavy dependency on /usr as it needs #!/usr/bin/python3 to run. So wouldn't it be happier in /usr/sbin?

I also note that it has dependencies on systemd. Will it work for systems not running systemd or will systemd be required for newer-versioned xfs maintenance?

Thnx...

Hmm, good point, scrub should move to /usr/sbin.

(Granted with many of the distros moving towards /sbin -> /usr/sbin these days it might not make that much difference... :/ )

/usr/lib/xfsprogs/xfs_scrub_all.cron is a sample cronjob that will get installed automatically some years from now when scrub is stable and ready to be autoconfigured as a background job. The goal is to be able to handle both systemd and cron environments, and I'm not picking sides. :)

(Note that xfs_scrub is still experimental...)

--D

----
Scrub, or the python script that uses it?
As far as I can tell, xfs_scrub, itself,
doesn't need anything on /usr.

-----
I was just looking at the xfs_scrub_all
cmd in /sbin. The cron you mention that is to run in a cron-only environment doesn't look right:

10 3 * * 0 root test -e /run/systemd/system || /sbin/xfs_scrub_all

It doesn't look like it will run w/o systemd directories.

I was looking at xfs_scrub_all and noticing that it was
heavily based on systemd, with references (in double quotes):

1) tail's output of "systemd-journal" (no facility to use syslog).
2) in fn "kill_systemd" uses systemd's "systemctl" to terminate a "systemd unit", with no option to kill a process via 'kill'
3) "escape a path to avoid systemd mangling" leaving need for utils reading paths from systemd to do their own decoding.

----
Yeah. Given the bit-ratio between content and
meta-info, I'd be more worried about some bit changing in the data, considering it covers a majority of the space. I.e. if metadata was 1/10000 of the data size, the chances of getting a bit changing in data would be 10,000 times higher.

It seems _remiss_ to go to all this work to check
the unlikely occurrence of random bit changes in metadata, when the chances of it happening in the data would be orders of magnitude higher.

OTOH, if one's HW does regular scans of the underlying
disk, wouldn't that be more efficient in detecting (and
repairing) random bit errors since it wouldn't have to read or seek around to extract semi-randomly placed metadata.

I see where xfs_scrub can allow speedup
using multiple threads, but with a hardware RAID, the speed-up goes up proportionately to the number of disks -- without the CPU being loaded down by such checking.

Somehow that seems considerably more efficient for finding random bit-errors.