On Fri, Dec 07, 2007 at 05:27:25 -0800, Anton B. Rang wrote: : > I was under the impression that real-time processes essentially trump all : > others, and I'm surprised by this behaviour; I had a dozen or so RT-processes : > sat waiting for disc for about 20s.
: Process priorities on Solaris affect CPU scheduling, but not (currently) : I/O scheduling nor memory usage. Ah, hmm. I hadn't appreciated that. I'm surprised. : > * Is this a ZFS issue? Would we be better using another filesystem? : It is a ZFS issue, though depending on your I/O patterns, you might be : able to see similar starvation on other file systems. In general, other : file systems issue I/O independently, so on average each process will : make roughly equal forward process on a continuous basis. You still : don't have guaranteed I/O rates (in the sense that XFS on SGI, for : instance, provides). That would make sense. I've not seen this before on any other filesystem. : > * Is there any way to mitigate against it? Reduce the number of iops : > available for reading, say? : > Is there any way to disable or invert this behaviour? : I'll let the ZFS developers tackle this one .... : --- : Have you considered using two systems (or two virtual systems) to ensure : that the writer isn't affected by reads? Some QFS customers use this : configuration, with one system writing to disk and another system : reading from the same disk. This requires the use of a SAN file system : but it provides the potential for much greater (and controllable) : throughput. If your I/O needs are modest (less than a few GB/second), : this is overkill. We're writing (currently) about 10MB/s; this may rise to about double that if we add the other multiplexes. We're taking the BBC's DVB content off-air, splitting it into programme chunks, and moving it from the machine that's doing the recording to a filestore. As it's off-air streams, we have no control over the inbound data -- it just arrives whether we like it or not. We do control the movement from the recorder to the filestore, but as this is largely achieved via a Perl module calling sendfile(), even that's mostly out of our hands. Definitely a headscratcher. -- Dickon Hood Due to digital rights management, my .sig is temporarily unavailable. Normal service will be resumed as soon as possible. We apologise for the inconvenience in the meantime. No virus was found in this outgoing message as I didn't bother looking. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
