Sequential disk IO saturates system

[grarpamp]

We have [re]nice to deal with user processes.

Is there no way to effectively rate limit the disk pipe? As it is
now, this machine can't do any userland work because it's completely
buried by the simple degenerate case of:
 cp /fs_a/.../giga_size_files /fs_b/...

Geli and zfs are in use, yet that doesn't seem to be an excuse for
this behavior.

I can read 60MB/s off the raw spindles without much issue.

Yet add geli and I get like 15MB/s, which is completely fine as
well, except the box gets swamped in system time when doing that.
And around 11MB/s off geli+zfs, caveat above swamping of course.

And although they perform at about the same MB/s rates, it's the
bulk writes that seem to thoroughly dispatch the system, far more
than the reads do. This one really hurts and removes all usability.

Sure, maybe one could set some ancient PIO mode on the [s]ata/scsi
channels [untested here]. But it seems far less than ideal as users
commonly mix raw and geli+zfs partitions on the same set of spindles.

Is there a description of the underlying issue available?

And unless I'm missing[?] something like an already existing insertable
geom rate limit, or a way to renice kernel processes...  is it right
to say that FreeBSD needs these options and/or some equivalent work
in this area?

As I'm without an empty raw disk right now, I can only write to zfs
and thus still have yet to test with writes to spindle and geli.
Regardless, perhaps the proper solution lies with the right sort
of future knob as in the previous paragraph?