As I wrote above, the device is taking long to finish the flush operation, and that's nothing special, but making the machine not react to input and actually block everything else like, say, the network stack and thereby interrupt downloads, is not what I perceive as fine.
Linus manages the kernel and should decide to include it as BFQ is just another option in a pluggable subsytem. BFQ is arguably more important than many things because it fixes bad performance and unresponsive behavior. I hope it's not that Jens Axboe has too much influence because he's the block layer maintainer.
Deadline so far in limited testing doesn't seem to cause lockups as CFQ does and it seems to more realistically reflect the workload in the form of lower MB/s during such phases. Thanks for the tip.
With blk-mq + nvme and later lightnvm that whole IO-scheduler mess will hopefully go away over the course of the next couple years (at least for personal computers).
I recall seeing something like that when input devices were living on the same hub as the storage device getting IO at the time. But that was years ago, and the USB stack has seen considerable work since.
Edit: never mind, Johnp_'s comment and bugzilla link is highly interesting.
