Am 09.01.19 um 11:54 schrieb Scott E. Blomquist:
> 
> Hi All,
> 
> I have a system that has been hanging/wedging frequently.  It seems to
> be load dependent but have not been able to isolate the problem.  The
> only option once the hang happens is to reboot via
> /proc/sysreq_trigger
> 
> btrfs fi df /export/
> Data, single: total=75.55TiB, used=75.54TiB
> System, single: total=36.00MiB, used=7.89MiB
> Metadata, single: total=187.01GiB, used=185.65GiB
> GlobalReserve, single: total=512.00MiB, used=0.00B


Within scheduler there were some changes according to device queueing.
Kernels after 4.16 and before 4.19.8 were problematic, as we recognized
here.
This seemed to be a regression on the "kyber" scheduler, as recognized here:
[root@pc7 sysctl.d]# cat /sys/block/sdc/queue/scheduler
mq-deadline [kyber] bfq none

As work around you may change the disc scheduler to an "old" one, like

Test it like this for all of your devices:
root@pc7:~/ # echo bfq > /sys/block/sdX/queue/scheduler

For permanent add a file config to your /etc/sysctl.d.
EXAMPLE, edit it to your requirements.

[root@pc7 sysctl.d]# cat /etc/sysctl.d/90-sysscheduler.conf
#disk scheduler
block.sda.queue.scheduler = md-deadline
block.sdb.queue.scheduler = md-deadline
block.sdg.queue.scheduler = bfq
block.sdh.queue.scheduler = bfq
block.sdi.queue.scheduler = bfq


Hope this may help you.
It did work for me here.

Better Idea is to upgrade the kernel to 4.19.13 (which is a LTS Kernel)

mit freundlichen Grüßen
Jürgen Sauer
-- 
Jürgen Sauer - automatiX GmbH,
+49-4209-4699, juergen.sauer@automatix.de
Geschäftsführer: Jürgen Sauer,
Gerichtstand: Amtsgericht Walsrode • HRB 120986
Ust-Id: DE191468481 • St.Nr.: 36/211/08000
GPG Public Key zur Signaturprüfung:
http://www.automatix.de/juergen_sauer_publickey.gpg