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

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

[L.A. Walsh]

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...

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

[Darrick J. Wong]

On Fri, Nov 02, 2018 at 08:59:21PM -0700, L.A. Walsh wrote:
> 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?

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... :/ )

> 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?

/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

> Thnx...
> 
> 
> 

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

[L A Walsh]

On 11/2/2018 9:52 PM, Darrick J. Wong wrote:
> On Fri, Nov 02, 2018 at 08:59:21PM -0700, L.A. Walsh wrote:
>>  'xfs_scrub_all' needs
>> #!/usr/bin/python3 to run.  So wouldn't it be happier in /usr/sbin?
> 
> Hmm, good point, scrub should move to /usr/sbin.
----
	Scrub, or the python script that uses it?
	As far as I can tell, xfs_scrub, itself, 
doesn't need anything on /usr.


> /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.
-----
	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.

> (Note that xfs_scrub is still experimental...)
----
	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.