On Thu, Dec 03, 2015 at 07:51:28PM -0500, Thor Lancelot Simon wrote: > > What strategy are you using to sort inside RAIDframe? This is a property > of the RAID set; you can see it with raidctl I believe for autoconfigured > sets. > > I wouldn't be terribly surprised to see bad interactions between > priocscan and RAIDframe's scan or cscan strategies. What about the "fifo" > strategy? It has been the fifo queuing method (queue size: 100) since 2010, when I created the set (based on the NetBSD RAIDframe guide). > It's important, though, to understand that there are *very* few pure bulk > read applications in this world (except single-stream video) and very > few pure bulk write applications except database logs. That means that > single-stream pure read or write tests are really pretty awful predictors > of disk performance for real workloads. I also tried a 5-stream dd test, based on one of your previous mails: https://mail-index.netbsd.org/netbsd-users/2014/12/01/msg015503.html All five streams got ~10MB/s each (bs=16k), more or less consistent with the bonnie++ output. I should retry that with priocscan. > The "priocscan" strategy, in particular, limits pure read/pure write > performance *by design* in order to achieve lower latency under real > world mixed workloads. Intuitively, I'd always expect some penalty by any kind of queueing, but for a simple sequential write, the numbers are just way off. These disks can sustain 100MB/s seq. reads and I assume it's not much worse when writing sequentially (unfortunately I can't test that now).. so 35MB/s seems broken and even 55MB/s kind of low.
Description: PGP signature