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? _______________________________________________ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
