>> Approximately 16 hours ago I've run a script that deleted >> >~100 snapshots and started quota rescan on a large >> USB-connected btrfs volume (5.4 of 22 TB occupied now). That "USB-connected is a rather bad idea. On the IRC channel #Btrfs whenever someone reports odd things happening I ask "is that USB?" and usually it is and then we say "good luck!" :-). The issues are: * The USB mass storage protocol is poorly designed in particular for error handling. * The underlying USB protocol is very CPU intensive. * Most importantly nearly all USB chipsets, both system-side and peripheral-side, are breathtakingly buggy, but this does not get noticed for most USB devices. >> Quota rescan only completed just now, with 100% load from >> [btrfs-transacti] throughout this period, > [ ... ] are different btrfs volumes independent in terms of > CPU, or are there some shared workers that can be point of > contention? As written that question is meaningless: despite the current mania for "threads"/"threadlets" a filesystem driver is a library, not a set of processes (all those '[btrfs-*]' threadlets are somewhat misguided ways to do background stuff). The real problems here are: * Qgroups are famously system CPU intensive, even if less so than in earlier releases, especially with subvolumes, so the 16 hours CPU is both absurd and expected. I think that qgroups are still effectively unusable. * The scheduler gives excessive priority to kernel threads, so they can crowd out user processes. When for whatever reason the system CPU percentage rises everything else usually suffers. > BTW, USB adapter used is this one (though storage array only > supports USB 3.0): > https://www.asus.com/Motherboard-Accessory/USB_31_TYPEA_CARD/ Only Intel/AMD USB chipsets and a few others are fairly reliable, and for mass storage only with USB3 with UASPI, which is basically SATA-over-USB (more precisely SCSI-command-set over USB). Your system-side card seems to be recent enough to do UASPI, but probably the peripheral-side chipset isn't. Things are so bad with third-party chipsets that even several types of add-on SATA and SAS cards are too buggy. -- 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
