On Thu, May 7, 2020 at 10:52 PM Andrew Pam <andrew@xxxxxxxxxxxxxx> wrote: > > 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. Is there anything else going on? What do you get for 'top -d 30' Autodefrag can sometimes be expensive, when it's doing copies in the background. This isn't inhibited during scrub. You do not need to put space_cache=v2 in fstab. It's a one time use, and it needs to be used with clear_cache. When you use it, a feature flag will be set that will cause it to be used automatically each time the file system mounts. Really the only thing that needs to be in there is 'noatime'. > > > 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 OK I screwed up the previous math. I love it when I do that. Since this is -d the numbers are for this device. 0.72T remaining 0.72×1024×1024÷151÷60÷60=1h23 Are there any messages in dmesg? All of these numbers look sane, compared to your first post. But that ETA keeps increasing suggests the scrub isn't proceeding at the reported rate. As if it's busy doing something else. -- Chris Murphy
