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