Re: btrfs-progs reports nonsense scrub status

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 7, 2020 at 10:42 PM Andrew Pam <andrew@xxxxxxxxxxxxxx> wrote:
>
> On 8/5/20 2:21 pm, Chris Murphy wrote:
> > What does 'iotop -d 10 -o' report? I'm expecting around 300MB/s reads.
>
> 91872 idle root      149.25 M/s    0.00 B/s  0.00 %  0.00 % btrfs scrub
> resume -c3 /home
> 91873 idle root      157.77 M/s    0.00 B/s  0.00 %  0.00 % btrfs scrub
> resume -c3 /home
>
> > The ETA is +14 hours what you posted 21 hours ago. So yeah that's
> > fakaked, but at least it's not saying it'll be done in year 5544!
>
> I did cancel when I went to bed and resumed when I got up three hours
> later on two occasions, so subtract six hours.
>
> > I've always seen the ETAs be pretty accurate so I don't know what's going on.
>
> Maybe it screws up once you cancel and resume too many times?
>
> > 3082813.44MB to go divided by 300MB/s is 171 minutes. Or just under 3
> > hours. So the time left / ETA is wrong based on this rate, if it's a
> > stable rate, which it might not be.
>
> I have an I/O load graph on my screen and it shows 100% read load on
> both drives at all times, with an I/O rate of around 130-160 M/s per drive.
>
> > What are the current mount options for this file system?
>
> /dev/sda on /home type btrfs
> (rw,noatime,space_cache,autodefrag,subvolid=5,subvol=/)
>
> Thanks,
>         Andrew

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.

Anyway, I'm pretty confident this scrub will finish in about 2.5 hours
if you just leave it as is.

-- 
Chris Murphy



[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux