reassign 1107480 src:xfsprogs
thanks
On Sun, Jun 08, 2025 at 09:50:53AM +0200, Klaus Wolf wrote:
>
> Problems in general:
> 1. Scrubbing is still considered experimental and therefore risky with
> some filesystems. (See kernel comments and log entries.)
> 2. In some environments, scrubbing would be considered outright
> destructive (when working on forensic media, e.g.)
> 3. It keeps I/O busy for no reason which is unwanted in business
> environments.
>
> Conclusion: The whole scrubbing scheduling by default should be abolished.
So first of all, for ext4, e2scrub is disabled by default. The
premise of this bug seems to be that for all file systems scrubbing is
enabled by default, and that's simply not true. For that reason, I've
disassociating this bug report from src:e2fsprogs.
I'll also note that e2scrub will never modify a file system. In fact,
the way e2scrub works is that it creates an LVM snapshot device, and
it runs the fsck on the snapshot device. So it will never modify the
file system (and so this isn't going to be an issue with forensic
media). It also only works if the file system is on a LVM's Logical
Volume, and there is space to create a small snapshot volume on the
LVM --- so this will generally not apply for forensic media.
E2scrub_all runs by default at Sunday at 3:10am localtime, which
generally won't interfere with business or personal workloads. Of
course, people who don't like that schedule can modify the timer file
before they enable e2scrub.
As far as xfs_scrub is concerned, I'll let the xfsprogs package
maintainer decide what they want to do, but given that the upstream
author of e2scrub is the same as xfs_scrub (and XFS on-line repair),
and we chat regularly on the weekly ext4 video conference, I'll make a
one comment:
By default xfs_scrub will do nothing (if parent pointers or reverse
mapping btrees are not enabled), or it will do a read-only check (for
modern v5 XFS file systems). With the reverse pointers, the I/O
needed to run the check operation is relatively small. It does appear
from my looking at things that the xfs_scrub is enabled by default
(and like e2scrub_all, it runs once a week on Sunday at 3:10am).
However, if you compare how much disk I/O xfs_scrub_all takes, and
compares it with regenerating the locatedb used by the locate command,
which is commonly installed on many systems, I suspect you'd find it
is roughly comparable --- and locate.timer is run every night, not
just once a week.
Finally, most novices are also not running regular backups, and if the
file system is corrupted, perhaps due to users purchasing the cheapest
possible cr*ppy flash devices, being warned early that the file system
may have suffered corruption might reduce the chances of the user
suffering massive, catastrophic data loss. The trade-off of having
some read-only I/O (so it won't negatively impact the write endurance
of your flash device) in the early morning on Sunday, is well worth it
in my opinion.
Personally, I like doing automated backups to a network-attached
storage device, which burns even more I/O bandwidth --- and I will
note that working for enterprise business environments as well as a
hyperscale cloud company (IBM and Google), the I/O bandwidth to make
sure data is not lost is considered cheap at the price.
It's only novices (that deserve all the data loss that they *will*
suffer that prioritize I/O bandwidth over data safety). Just consider
what the business value of your data might be, and the cost of a human
being to try to do desparation data recover, versus an extra HDD or
SSD, and it's just not a contest. And in a non-business, personal
context, how much would you value pictures of your children taking
their first steps getting lost due to a data corruption incident?
We can debate what the defaults "should" be, but the wise system
administrator would enable them.
Cheers,
- Ted
