Re: zfs with operations like rm -rf takes a very long time recently

The usual reason why rm gets slow is because your pool is nearly full
and there's a snapshot.  A snapshot means that rm doesn't actually
free space; it just rewrites metadata, which requires even more space.
And when a zpool is nearly full, writes always slow way down.
But if that's not it, then you should also check gstat to see if the
disk itself is slow.

On Sun, Oct 16, 2022 at 7:57 AM void <void@f-m.fm> wrote:
>
> Has anything recently changed in -current that would make file operations
> on zfs such as rm -rf *.* very slow?
>
> What would I look for and how would I test it?
>
> system is FreeBSD 14.0-CURRENT #5 main-n258595-226e41467ee1 on arm64.aarch64
> using GENERIC-NODEBUG kernel.
>
> the zfs is zroot on usb3 on a raspberry pi4 8GB. there appears to be plenty
> of resources. cpu speed is 2.1GHz. zroot is external usb3 hd.
>
> Right now it's rm -rf-ing /var/cache/ccache/* which is 5GB max and it's taken
> over 10 mins. It was never this slow. No errors in /var/log/messages and none
> yet in smartd. zpool scrub last ran successfully 3 days ago.
>
> last pid:  4324;  load averages:  0.17,  0.10,  0.12                                                      up 0+02:10:34  14:40:55
> 77 processes:  1 running, 76 sleeping
> CPU:  1.6% user,  0.0% nice,  1.9% system,  0.2% interrupt, 96.4% idle
> Mem: 550M Active, 803M Inact, 2224M Wired, 40K Buf, 4239M Free
> ARC: 1293M Total, 381M MFU, 725M MRU, 1124K Anon, 30M Header, 156M Other
>      938M Compressed, 1906M Uncompressed, 2.03:1 Ratio
> Swap: 16G Total, 16G Free
> Process id to show (+ for all):
>   PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
>  3871 root          1  20    0    12M  3648K zio->i   2   0:10   0.39% rm
>   353 _pflogd       1  20    0    13M  2108K bpf      1   0:00   0.00% pflogd
>  1441 mailnull      1  28    0    25M  9508K select   3   0:01   0.00% exim
>
> TIA,
>