Control: forwarded -1 https://github.com/kdave/btrfsmaintenance/pull/66
Dear Philip, Philip <phlo...@gmail.com> writes: > Package: btrfsmaintenance > Version: 0.4.2-1 > Followup-For: Bug #908467 > > Dear Maintainer, > > This bug is actually preventing Debian to work as a multimedia server like > Plex, because during scrubbing, everything else becomes very slow and > unresponsive and with even a few TB to scrub, it takes already almost two days > (in my case 38h). > So this bug is actually for me more urgent than for the the other poster. > I've also noticed that btrfs has gotten slower sometime post ~linux-4.9 (with defaults), and I wish the fix proposed in this bug actually resolved it. Given that with btrfs a syncthing update of several thousand files will also slow a desktop down to an unusable state, I agree with upstream that it's a kernel issue. For a server, I've had best results with the old non-multiqueue scheduler and CFQ, and for desktop I schedule scrubs or defrags for times I won't be using the system and use the non-multiqueue deadline scheduler--this is documented on our wiki. In the worst-case scenario, I wonder if ancient (but still existing) kernel issue that makes a desktop unusable when a USB drive is maxed out with IO (any filesystem) is what causes this effect. eg: that btrfs is guaranteed to trigger the same condition on any type of drive that is otherwise triggered by drive that has slow IO and high iowait (with any filesystem). > Thanks though for your work > You're welcome. Sorry this long-standing issue still exists (broader issue than btrfsmaintenance)...back in 2015 I fully expected it to be resolved by now. The wiki documents a bunch of things that make this problem worse (eg: using compression, keeping snapshots around, filling the disk more than ~80% full, etc). Not a real solution, I know... P.S. I'm also testing a zfs system, and its performance also falls off a cliff when an aged fs is above ~80% capacity--and once that happens, removing of files will never restore the old performance. That's why I prefer btrfs, despite the known cases that cause terrible performance. Regards, Nicholas
signature.asc
Description: PGP signature
