Re: priocscan vs fcfs

[mlelstv%serpens.de@localhost (Michael van Elst)]

imil%home.imil.net@localhost ("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: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."