[Captivate General] FireMedicDave:
I found some great definitions of for noop, anticipatory, deadline, cfq on this website...

www dot admon dot org/a-comparison-of-io-schedulers/

The site won't let me put in a link so put a period where "dot" is.

Here they are...

Noop - Noop is the simplest scheduler present in Linux. It is mostly suitable for truly random-access block devices, such as flash memory

cards. The incoming requests for read/write are kept in FIFO order, and only the current request added at the end of the queue is tested for

the possibility of merging. The downside is clear; you get no optimization at all, especially in situations where there are many

competing read/write processes. Per process sequential readings will be seen as “random” access. So, it’s better not to use this scheduler with

any sequential access device, such as a hard disk.

Anticipatory - The Anticipatory scheduler is designed around the fact that a user tends to access adjacent sectors instead of jumping to other disk areas

during certain periods of time. Most file systems in Linux use a specific approach to ensure that sectors belonging to a file are kept

adjacent as much as possible. Between these reads, it is very likely that the task sleeps for a while before continuing reading.

So, the basic idea behind the Anticipatory scheduler is that it anticipates subsequent reads between sleeps. By staying a bit longer in

the same head position, it can reduce the back-and-forth seek movement to a certain degree. How long it should stay is sometimes determined by

looking into the next incoming read request, or in some cases by forecasting based on statistics. It is clear then that the Anticipatory

scheduler isn’t really great for time-sensitive read/write processes. The CFQ scheduler shares the same cons, although it is a bit better

because of its “fairness” ability, which we’ll describe later.

Deadline - If you have a lot of requests, you may want to make sure a request is serviced within a strict period of time. This situation is quite

common for a busy file server, but you can see it on desktop workload, too (e.g., graphics rendering). The Deadline scheduler was created to

address this need. Read and write processes are guaranteed to be serviced within a strict amount of time, and read is prioritized over

write. So, the Deadline scheduler pays attention to latency issues but not necessarily throughput.

Read is favored over write, because read is assumed to be more important; however, write operations aren’t allowed to be starved too

much. This behavior can also be tweaked with some tunables, which we’ll talk more about later.

The Deadline scheduler is a sound fit for high-performance I/O because it decreases the interactivity to a certain degree. For someone who

demands smooth desktop experience, however, this might not be the scheduler to choose.

CFQ - CFQ is the default scheduler used in the latest kernel versions, and it is typically suited for people seeking balanced I/O service. Stressing

“fairness”, it tries to manage read/write processes using priorities so that nothing dominates or fully dictates the way the kernel serves

these requests. This is done by dividing the bandwidth of each block device fairly among the processes performing I/O to that device. Lately

it has also been improved by the time slice-based operation, meaning it does what process schedulers do: Serves a request within a specific

duration, stops, switches to another one, and repeats.

When a process submits a request for disk access, the request can be classified as synchronous or asynchronous. In the case of synchronous

requests, the process waits for the request’s completion; for asynchronous requests, it simply sends the request to disk and starts

doing some other work. Hence, the CFQ scheduler gives more time/priority to synchronous requests rather than to asynchronous

requests. CFQ gives the best balance (theoretically) between throughput and interactivity.