i...@home.imil.net ("Emile `iMil' Heitor") writes: >as changing it only for the disk members was apparently counter-productive. >And there we go, from a 40/50MB/s write average to a stunning 200 to 300MB/s, >which is more like what the disks can theroically do.
>Could anyone with some background on these strategies explain what's behind the >curtain? I couldn't really find precise documentation on this matter... disksort - execute requests in order of increasing block numbers, then continue with the lowest block number. I.e. do a one-way scan over the disk. fcfs - execute requests in the order they were issued. priocscan - The filesystem tags each I/O request (buffer) with a priority. Priorities are mapped to multiple queues, the highest priority queue is executed first, each queue is executed in block number order up to a fixed number of requests (burst) to prevent the lower priority queues from starving. "block number order" can be just "cylinder number order" depending on the disk driver. buffer priority is time-noncritical (low), time-limited (medium) and time-critical (high). Usually synchronous operations and the journal are time-critical, everything else is time-limited and time-noncritical isn't used. Accessing the raw device is also time-critical. So, disksort is the traditional method for filesystems on dumb disk devices. fcfs can be good for smart disks with caches and their own queuing and for streaming a raw disk. Priocscan tries to optimize for concurrent filesystem accesses better than disksort. fcfs is also the "neutral" queue for drivers stacking on top of each other. The queue sorting should really only be done at one level. But raidframe is more complicated because it does its own queuing and sorting outside of this schema, in particular when it has to read-modify-write stripe sets for small I/O. That's probably why setting the queues all to fcfs is the best for you. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."