fileio: add brief explanations for flags

[thirdparty/systemd.git] / man / crypttab.xml

diff --git a/man/crypttab.xml b/man/crypttab.xml
index 2046911c7849517771c627b6ec39c08ee58d4420..ee54499bfe7a13c86869b3c7c4e355a0e7d511a5 100644 (file)
--- a/man/crypttab.xml
+++ b/man/crypttab.xml
@@ -60,13 +60,15 @@
     device or file, or a specification of a block device via
     <literal>UUID=</literal> followed by the UUID.</para>
 
-    <para>The third field specifies an absolute path to a file to read the encryption key from. If the field
-    is not present or set to <literal>none</literal> or <literal>-</literal>, a key file named after the
-    volume to unlock (i.e. the first column of the line), suffixed with <filename>.key</filename> is
-    automatically loaded from the <filename>/etc/cryptsetup-keys.d/</filename> and
-    <filename>/run/cryptsetup-keys.d/</filename> directories, if present. Otherwise, the password has to be
-    manually entered during system boot. For swap encryption, <filename>/dev/urandom</filename> may be used
-    as key file.</para>
+    <para>The third field specifies an absolute path to a file to read the encryption key from. Optionally,
+    the path may be followed by <literal>:</literal> and an fstab device specification (e.g. starting with
+    <literal>LABEL=</literal> or similar); in which case, the path is relative to the device file system
+    root. If the field is not present or set to <literal>none</literal> or <literal>-</literal>, a key file
+    named after the volume to unlock (i.e. the first column of the line), suffixed with
+    <filename>.key</filename> is automatically loaded from the <filename>/etc/cryptsetup-keys.d/</filename>
+    and <filename>/run/cryptsetup-keys.d/</filename> directories, if present. Otherwise, the password has to
+    be manually entered during system boot. For swap encryption, <filename>/dev/urandom</filename> may be
+    used as key file.</para>
 
     <para>The fourth field, if present, is a comma-delimited list of
     options. The following options are recognized:</para>
@@ -253,6 +255,7 @@
 
         <listitem><para>Perform encryption using the same cpu that IO was submitted on. The default is to use
         an unbound workqueue so that encryption work is automatically balanced between available CPUs.</para>
+
         <para>This requires kernel 4.0 or newer.</para>
         </listitem>
       </varlistentry>
@@ -261,9 +264,10 @@
         <term><option>submit-from-crypt-cpus</option></term>
 
         <listitem><para>Disable offloading writes to a separate thread after encryption. There are some
-        situations where offloading write bios from the encryption threads to a single thread degrades
-        performance significantly. The default is to offload write bios to the same thread because it benefits
-        CFQ to have writes submitted using the same context.</para>
+        situations where offloading write requests from the encryption threads to a dedicated thread degrades
+        performance significantly. The default is to offload write requests to a dedicated thread because it
+        benefits the CFQ scheduler to have writes submitted using the same context.</para>
+
         <para>This requires kernel 4.0 or newer.</para>
         </listitem>
       </varlistentry>
@@ -510,7 +514,8 @@ external   /dev/sda3       keyfile:LABEL=keydev keyfile-timeout=10s</programlist
 
       <para>The PKCS#11 logic allows hooking up any compatible security token that is capable of storing RSA
       decryption keys. Here's an example how to set up a Yubikey security token for this purpose, using
-      <command>ykman</command> from the yubikey-manager project:</para>
+      <citerefentry project='debian'><refentrytitle>ykmap</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      from the yubikey-manager project:</para>
 
 <programlisting><xi:include href="yubikey-crypttab.sh" parse="text" /></programlisting>