On 8/5/20 2:45 pm, Chris Murphy wrote: > I don't know if space_cache v1 can negatively impact scrubs but it > does negatively impact other things especially on larger file systems > with a lot of free space remaining. v1 cache exists as data blocks, v2 > cache is a dedicated 'free space tree' and resides in fs metadata. > It's the inverse of the extent tree. > > A conservative approach that might speed things up: > > # mount -o remount,clear_cache,nospace_cache /mnt > > Once it's done: > > # mount -o remount,clear_cache,space_cache=v2 /mnt > > This sets a feature flag, and the next time you mount normally, it'll > use v2. You could do this now during the scrub, but it might slow it > down a bit while the new cache is being created. If the file system > isn't busy it might take a minute to build. Thanks, I didn't know that - I just used the defaults in /etc/fstab as follows: UUID=85069ce9-be06-4c92-b8c1-8a0f685e43c6 /home btrfs defaults,autodefrag,noatime I'll put space_cache=v2 in there as well. > Anyway, I'm pretty confident this scrub will finish in about 2.5 hours > if you just leave it as is. I'm not. It's still not reporting any forward progress, just moving the ETA ahead: $ sudo btrfs scrub status -d /home UUID: 85069ce9-be06-4c92-b8c1-8a0f685e43c6 scrub device /dev/sda (id 1) status Scrub started: Thu May 7 15:44:21 2020 Status: running Duration: 5:40:13 Time left: 1:23:04 ETA: Fri May 8 16:11:31 2020 Total to scrub: 3.66TiB Bytes scrubbed: 2.94TiB Rate: 151.16MiB/s Error summary: no errors found scrub device /dev/sdb (id 2) status Scrub started: Thu May 7 15:44:21 2020 Status: running Duration: 5:40:16 Time left: 1:18:09 ETA: Fri May 8 16:06:36 2020 Total to scrub: 3.66TiB Bytes scrubbed: 2.98TiB Rate: 152.92MiB/s Error summary: no errors found Thanks, Andrew
