Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Raid5 scrub really slow. #85

Open
mittkonto opened this issue Sep 15, 2020 · 2 comments
Open

Raid5 scrub really slow. #85

mittkonto opened this issue Sep 15, 2020 · 2 comments

Comments

@mittkonto
Copy link

Hi, trying out raid5 with the "new" raid1c3/4 profiles. It's slow by it's nature, but..

Noticed scrub crawls 12MiB/s when I usually get 40MiB/s, also I'd rather scrub one disc at the time.
It seems to be a thing.

I added "BTRFS_SCRUB_MOUNTPOINTS="/dev/sda1:/dev/sdb1:/dev/sdc1:/dev/sdd1" in /etc/default/btrfsmaintenance

But it does not seem to catch on when I: sudo systemctl start btrfs-scrub:

btrfs-scrub.service - Scrub btrfs filesystem, verify block checksums
     Loaded: loaded (/usr/lib/systemd/system/btrfs-scrub.service; static)
     Active: inactive (dead) since Tue 2020-09-15 17:57:46 CEST; 2s ago
TriggeredBy: ● btrfs-scrub.timer
       Docs: man:fstrim
    Process: 63436 ExecStart=/usr/share/btrfsmaintenance/btrfs-scrub.sh (code=exited, status=0/SUCCESS)
   Main PID: 63436 (code=exited, status=0/SUCCESS)

Sep 15 17:57:46 host btrfs-scrub[63442]: Path /dev/sda1 is not btrfs, skipping
Sep 15 17:57:46 host btrfs-scrub[63442]: Running scrub on /dev/sdb1
Sep 15 17:57:46 host btrfs-scrub[63442]: Path /dev/sdb1 is not btrfs, skipping
Sep 15 17:57:46 host btrfs-scrub[63442]: Running scrub on /dev/sdc1
Sep 15 17:57:46 host btrfs-scrub[63442]: Path /dev/sdc1 is not btrfs, skipping
Sep 15 17:57:46 host btrfs-scrub[63442]: Running scrub on /dev/sdd1
Sep 15 17:57:46 host btrfs-scrub[63442]: Path /dev/sdd1 is not btrfs, skipping
Sep 15 17:57:46 host systemd[1]: btrfs-scrub.service: Succeeded.
@likeman9
Copy link

likeman9 commented Dec 8, 2020

Only need RAID1 for metadata on RAID5 if 2 disks fail you lose everything anyway but not really a bad thing having more metadata redundancy (it's RAID6 you use RAID1c3 so it can still function with 2 disks missing)

But yes it be nice if the btrfs scrub command was smarter on scrubbing on raid56 so it's not acing 2-4x read impact on each disk witch is very bad for hdds

Should script a batch run for scrub 1 at a time per disk (just have it wait until it has finished)

@bdelwood
Copy link

bdelwood commented Feb 1, 2021

You get <device> is not btrfs because the helper function that checks for a btrfs filesystem, is_btrfs, uses stat, which returns tmpfs on block devices.

A fix for this would be to change the helper function in btrfsmaintenance-functions so that it uses blkid, which can handle block devices.

So is_btrfs should look like this:

is_btrfs() {
	local FS=$(blkid -o value -s TYPE "$1")
	[ "$FS" = "btrfs" ] && return 0
	return 1
}

I just replaced stat -f --format=%T "$1" with blkid -o value -s TYPE "$1".

Then running a scrub with the block devices in BTRFS_SCRUB_MOUNTPOINTS will scrub each disk separately in the order given.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants