Re: New service e2scrub_reap

["Theodore Ts'o" <tytso@mit.edu>]

On Mon, Mar 18, 2019 at 12:24:55PM +0100, Paul Menzel wrote:
> Dear Ted, dear Darrick,
> 
> On Debian Sid/unstable, I noticed the new service `scrub/e2scrub_reap.service`
> installed in the default target [1][2].
> 
> $ systemctl status -o short-precise e2scrub_reap.service
> ● e2scrub_reap.service - Remove Stale Online ext4 Metadata Check Snapshots
>    Loaded: loaded (/lib/systemd/system/e2scrub_reap.service; enabled; vendor preset: enabled)
>    Active: inactive (dead) since Mon 2019-03-18 12:17:13 CET; 1min 1s ago
>      Docs: man:e2scrub_all(8)
>   Process: 447 ExecStart=/sbin/e2scrub_all -A -r (code=exited, status=0/SUCCESS)
>  Main PID: 447 (code=exited, status=0/SUCCESS)
> 
> Mar 18 12:17:08.223560 plumpsklo systemd[1]: Starting Remove Stale Online ext4 Metadata Check Snapshots...
> Mar 18 12:17:13.996465 plumpsklo systemd[1]: e2scrub_reap.service: Succeeded.
> Mar 18 12:17:13.996808 plumpsklo systemd[1]: Started Remove Stale Online ext4 Metadata Check Snapshots.

Yeah, that's unfortunate.  I'm seeing a similar time on my (fairly
high-end) laptop:

# time e2scrub_all -A -r 

real	0m4.356s
user	0m0.677s
sys	0m1.285s


We should be able to fix this in general by avoiding the use of lsblk
at all, and in the case of e2scrub -r, just simply iterating over the
output of:

lvs --name-prefixes -o vg_name,lv_name,lv_path,origin -S lv_role=snapshot

(which takes about a fifth of a second on my laptop and it should be
even faster if there are no LVM volumes on the system)

And without the -r option, we should just be able to do this:

lvs --name-prefixes -o vg_name,lv_name,lv_path -S lv_active=active,lv_role=public

Right now we're calling lvs for every single block device emitted by
lsblk, and from what I can tell, we can do a much better job
optimizing e2scrub_all.

> Reading the manual, the switch `-r` “removes e2scrub snapshots but do not
> check anything”.
> 
> Does this have to be done during boot-up, or could it be done after the
> default target was reached, or even during shutting down?

This shouldn't be blocking any other targets, I think there should be
a way to configure the unit file so that it runs in parallel with the
other systemd units.  My systemd-fu is not super strong, so I'll have
to do some investigating to see how we can fix this.

Regards,

					- Ted