man: tweak description of blockdev@.target

In particular, let's just say "is" and "must" instead of "may be" and
"should". The weaker forms are obviously correct, but the text is easier to
understand if non-conditional forms are used.
This commit is contained in:
Zbigniew Jędrzejewski-Szmek 2020-02-04 16:40:52 +01:00
parent dc9fd22d3d
commit 8e92d92fb8
1 changed files with 12 additions and 13 deletions

View File

@ -848,20 +848,19 @@
<variablelist>
<varlistentry>
<term><filename>blockdev@.target</filename></term>
<listitem><para>This template unit may be used to order mount units and other consumers of block
devices against services that synthesize these block devices. This is intended to be used to order
storage services (such as
<listitem><para>This template unit is used to order mount units and other consumers of block
devices after services that synthesize these block devices. In particular, this is intended to be
used with storage services (such as
<citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>)
that allocate and manage a virtual block device against mount units and other consumers of
it. Specifically, the storage services are supposed to be orderd before an instance of
<filename>blockdev@.target</filename>, and the mount unit (or other consuming unit, such as a swap
unit) after it. The ordering is particular relevant during shutdown, as it ensures that the mount
is deactivated first and the service backing the mount only deactivated after that completed. The
<filename>blockdev@.target</filename> instance should be pulled in via a <option>Wants=</option>
dependency of the storage daemon and thus generally not be part of any transaction unless a storage
daemon is used. The instance name for instances of this template unit is supposed to be the
properly escaped bock device node path, e.g. <filename>blockdev@dev-mapper-foobar.target</filename>
for a storage device <filename>/dev/mapper/foobar</filename>.</para></listitem>
that allocate and manage a virtual block device. Storage services are ordered before an instance of
<filename>blockdev@.target</filename>, and the consumer units after it. The ordering is
particularly relevant during shutdown, as it ensures that the mount is deactivated first and the
service backing the mount later. The <filename>blockdev@.target</filename> instance should be
pulled in via a <option>Wants=</option> dependency of the storage daemon and thus generally not be
part of any transaction unless a storage daemon is used. The instance name for instances of this
template unit must be a properly escaped block device node path, e.g.
<filename>blockdev@dev-mapper-foobar.target</filename> for the storage device
<filename>/dev/mapper/foobar</filename>.</para></listitem>
</varlistentry>
<varlistentry>
<term><filename>cryptsetup-pre.target</filename></term>