processed bios then form an I/O request which is handed to an <em>
I/O scheduler </em> (also known as <em> elevator</em>). </p>
-<p> At this time of writing (2018-11) there exist two different sets
-of schedulers: the traditional single-queue schedulers and the
-modern multi-queue schedulers, which are expected to replace the
-single-queue schedulers soon. The three single-queue schedulers,
-noop, deadline and cfq (complete fair queueing), were designed for
-rotating disks. They reorder requests with the aim to minimize seek
-time. The newer multi-queue schedulers, mq-deadline, kyber, and bfq
-(budget fair queueing), aim to max out even the fastest devices. As
-implied by the name "multi-queue", they implement several request
-queues, the number of which depends on the hardware in use. This
-has become necessary because modern storage hardware allows multiple
-requests to be submitted in parallel from different CPUs. Moreover,
-with many CPUs the locking overhead required to put a request into
-a queue increases. Per-CPU queues allow for per-CPU locks, which
-decreases queue lock contention. </p>
+<p> Traditionally, the schedulers were designed for rotating disks.
+They implemented a single request queue and reordered the queued
+I/O requests with the aim to minimize disk seek times. The newer
+multi-queue schedulers mq-deadline, kyber, and bfq (budget fair
+queueing) aim to max out even the fastest devices. As implied by
+the name "multi-queue", they implement several request queues,
+the number of which depends on the hardware in use. This has become
+necessary because modern storage hardware allows multiple requests
+to be submitted in parallel from different CPUs. Moreover, with many
+CPUs the locking overhead required to put a request into a queue
+increases. Per-CPU queues allow for per-CPU locks, which decreases
+queue lock contention. </p>
<p> We will take a look at some aspects of the Linux block layer and on
the various I/O schedulers. An exercise on loop devices enables the
SECTION(«LVM Snapshots»)
-<p> LVM snapshots are based on the CoW optimization
-strategy described earlier in the chapter on <a
-href="./Unix_Concepts.html#the_virtual_address_space_of_a_unix_process">Unix
-Concepts</a>. Creating a snapshot means to create a CoW table of
-the given size. Just before a LE of a snapshotted LV is about to be
-written to, its contents are copied to a free slot in the CoW
-table. This preserves an old version of the LV, the snapshot, which
-can later be reconstructed by overlaying the CoW table atop the LV.
+<p> LVM snapshots are based on the CoW optimization strategy described
+earlier in the chapter on <a href="./Unix_Concepts.html#processes">Unix
+Concepts</a>. Creating a snapshot means to create a CoW table of the
+given size. Just before a LE of a snapshotted LV is about to be written
+to, its contents are copied to a free slot in the CoW table. This
+preserves an old version of the LV, the snapshot, which can later be
+reconstructed by overlaying the CoW table atop the LV. </p>
<p> Snapshots can be taken from a LV which contains a mounted file system,
while applications are actively modifying files. Without coordination
target_args</code>. Determine the correct values for the first three
arguments to encrypt <code> /dev/loop0</code>. </li>
- <li> The <code> target_args </code> for the dm-crypt target are
- of the form <code> cipher key iv_offset device offset</code>. To
- encrypt <code> /dev/loop0 </code> with AES-256, <code> cipher </code>
- is <code> aes</code>, device is <code> /dev/loop0 </code> and both
- offsets are zero. Come up with an idea to create a 256 bit key from
- a passphrase. </li>
+ <li> The <code>target_args</code> for the dm-crypt target are
+ of the form <code>cipher key iv_offset device offset</code>. To
+ encrypt <code>/dev/loop0</code> with AES-256, <code>cipher</code>
+ is <code>aes</code>, <code>device</code> is <code>/dev/loop0</code>
+ and both offsets are zero. Come up with an idea to create a 256 bit
+ key from a passphrase. </li>
<li> The <code> create </code> subcommand of <code> dmsetup(8)
</code> creates a device from the given table. Run a command of
projects / aple.git / blobdiff