shuppy (@delan) — [archived]
shuppy (@delan) — [archived]

waow this one small trick will make your zpool scrub faster!!

in openzfs dsl_scan.c, changing `scn->scn_phys.scn_min_txg` from 0 to 7000000 in dsl_scan_setup_sync zpool status after scrubbing with stock zfs 2.2.4, taking over seven minutes zpool status after scrubbing with patched zfs 2.2.4, taking just over two minutes and issuing reads for only 316GiB of the 970GiB pool

(not really. i’m just patching zfs to reproduce a bug that happens near the end of a scrub)

shuppy (@delan) — [archived]

we’ve done it. blazingly fast, zero-cost scrubbing

zpool status reporting “scan: scrub repaired 0B in 00:00:00 with 0 errors on Fri May 17 00:56:15 2024”
shuppy (@delan) — [archived]

one small problem. i have no idea what range of txgs i want to scrub

in openzfs dsl_scan.c, adding some dataset name checks in `dsl_scan_visitds` that set one new flag `is_target_or_descendant` if the dataset is cuffs/code (or a snapshot or descendant), or another new flag `is_potential_ancestor` if the dataset is cuffs (or a snapshot or descendant). this gets used later to skip scrubbing and/or recursing the dataset (not pictured) zpool status after scrubbing with this new patch, showing that the scrub finished in 00:01:17 after issuing reads for only 105G of the 971G pool. zfs list in another terminal shows that cuffs/code is only 106G

friendship ended with world’s most scuffed reimplementation of openzfs/zfs#15250. now world’s most scuffed reimplementation of openzfs/zfs#7257 is my best friend