TL;DR scrub's ioprio argument isn't really helpful - a scrub murders
system performance til it's done.
My system:
3.11 kernel (from Ubuntu Saucy)
btrfs-tools from 2013-07 (from Debian Sid)
Opteron 8-core CPU
32GB RAM
4 WD 1TB Black drives in a btrfs RAID10 (data and metadata).
iotop shows that the idle priority really is set on the processes:
>> me@box:~$ sudo iotop -bn 1 | grep idle
>> 28326 idle root 82.06 M/s 0.00 B/s 0.00 % 0.00 % btrfs
scrub start -c3 /data
>> 28327 idle root 89.30 M/s 0.00 B/s 0.00 % 0.00 % btrfs
scrub start -c3 /data
>> 28329 idle root 84.47 M/s 0.00 B/s 0.00 % 0.00 % btrfs
scrub start -c3 /data
>> 28331 idle root 79.64 M/s 0.00 B/s 0.00 % 0.00 % btrfs
scrub start -c3 /data
But unfortunately, despite being on "idle" priority, the scrub is
KILLING system performance. This is one of my eight CPU cores. Any core
with a significant amount of non-idle time has three to four times as
much wait time as it does user/system time. Brutal:
>> Cpu4 : 4.4%us, 16.1%sy, 0.0%ni, 12.4%id, 67.2%wa, 0.0%hi,
0.0%si, 0.0%st
Anybody got any ideas that might make the scrub go a little less...
enthusiastically... and leave the system more usable? Right now, with a
scrub running, the system is so burdened that it may take as much as two
to three seconds to so much as display a manpage. God help you if you
want to, say, log into a VM running on the system. It'll GET there, but
it'll look like it's iSCSI on TCP over carrier pigeon.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
