On Thu, Mar 18, 2010 at 09:54:28PM -0700, Tonmaus wrote: > > (and the details of how much and how low have changed a few times > > along the version trail). > > Is there any documentation about this, besides source code?
There are change logs and release notes, and random blog postings along the way - they're less structured but often more informative. There were some good descriptions about the scrub improvements 6-12 months ago. The bugid's listed in change logs that mention scrub should be pretty simple to find and sequence with versions. > > However, that prioritisation applies only within the kernel; sata > > disks don't understand the prioritisation, so once the requests > > are with the disk they can still saturate out other IOs that made > > it to the front of the kernel's queue faster. > > I am not sure what you are hinting at. I initially thought about TCQ > vs. NCQ when I read this. But I am not sure which detail of TCQ > would allow for I/O discrimination that NCQ doesn't have. Er, the point was exactly that there is no discrimination, once the request is handed to the disk. If the internal-to-disk queue is enough to keep the heads saturated / seek bound, then a new high-priority-in-the-kernel request will get to the disk sooner, but may languish once there. You'll get best overall disk throughput by letting the disk firmware optimise seeks, but your priority request won't get any further preference. Shortening the list of requests handed to the disk in parallel may help, and still keep the channel mostly busy, perhaps at the expense of some extra seek length and lower overall throughput. You can shorten the number of outstanding IO's per vdev for the pool overall, or preferably the number scrub will generate (to avoid penalising all IO). The tunables for each of these should be found readily, probably in the Evil Tuning Guide. > All I know about command cueing is that it is about optimising DMA > strategies and optimising the handling of the I/O requests currently > issued in respect to what to do first to return all data in the > least possible time. (??) Mostly, as above it's about giving the disk controller more than one thing to work on at a time, and having the issuance of a request and its completion overlap with others, so the head movement can be optimised and the controller channel can be busy with data transfer for another while seeking. Disks with write cache effectively do this for writes, by pretending they complete immediately, but reads would block the channel until satisfied. (This is all for ATA which lacked this, before NCQ. SCSI has had these capabilities for a long time). > > If you're looking for something to tune, you may want to look at > > limiting the number of concurrent IO's handed to the disk to try > > and avoid saturating the heads. > > Indeed, that was what I had in mind. With the addition that I think > it is as well necessary to avoid saturating other components, such > as CPU. Less important, since prioritisation can be applied there too, but potentially also an issue. Perhaps you want to keep the cpu fan speed/noise down for a home server, even if the scrub runs longer. > I have two systems here, a production system that is on LSI SAS > (mpt) controllers, and another one that is on ICH-9 (ahci). Disks > are SATA-2. The plan was that this combo will have NCQ support. On > the other hand, do you know if there a method to verify if its > functioning? AHCI should be fine. In practice if you see actv > 1 (with a small margin for sampling error) then ncq is working. -- Dan.
pgpIQ2VrNVyJl.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
