<!ENTITY dhemail "<email>wouter@debian.org</email>">
<!ENTITY dhusername "Wouter Verhelst">
<!ENTITY dhucpackage "<refentrytitle>NBD-SERVER</refentrytitle>">
- <!ENTITY dhpackage "@sysconfdir@/nbd-server/config">
+ <!ENTITY dhpackage "$sysconfdir/nbd-server/config">
<!ENTITY debian "<productname>Debian GNU/Linux</productname>">
<!ENTITY gnu "<acronym>GNU</acronym>">
<refsect1>
<title>DESCRIPTION</title>
- <para><command>&dhpackage;</command> allows to configure the
- nbd-server.</para>
+ <para>This file allows to configure the nbd-server.</para>
<para>While
- <filename>@sysconfdir@/nbd-server/config</filename> is the default
+ <filename>$sysconfdir/nbd-server/config</filename> is the default
configuration file, this can be varied with the <option>-C</option>
option to <command>nbd-server</command>(1).
</para>
<listitem>
<para>
Optional; string; default
- <filename>@sysconfdir@/nbd-server/allow</filename>.
+ <filename>$sysconfdir/nbd-server/allow</filename>.
</para>
<para>
The name of the authorization file for this export. This
</listitem>
</varlistentry>
<varlistentry>
+ <term><option>flush</option></term>
+ <listitem>
+ <para>Optional; boolean.</para>
+ <para>When this option is enabled,
+ <command>nbd-server</command> will inform the client that it
+ supports and desires to be sent flush requests when the
+ elevator layer receives them. Receipt of a flush request
+ will cause an fdatasync() (or, if the sync option is set,
+ an fsync()) on the backend storage. This increases
+ reliability in the case of an unclean shutdown at
+ the expense of a degradation of performance. The default
+ state is disabled. This option will have no effect unless
+ supported by the client.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>fua</option></term>
+ <listitem>
+ <para>Optional; boolean.</para>
+ <para>When this option is enabled,
+ <command>nbd-server</command> will inform the client that it
+ supports and desires to be sent fua (force unit access) commands
+ when the elevator layer receives them. Receipt of a force unit
+ access command will cause the specified command to be synced
+ to backend storage using sync_file_range() if supported, or
+ fdatasync() otherwise. This increases
+ reliability in the case of an unclean shutdown at
+ the expense of a degradation of performance. The default
+ state is disabled. This option will have no effect unless
+ supported by the client.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>rotational</option></term>
+ <listitem>
+ <para>Optional; boolean.</para>
+ <para>When this option is enabled,
+ <command>nbd-server</command> will inform the client that it
+ it would prefer it to send requests in elevator order, perhaps
+ because it has a backing store and no local elevator. By
+ default, the client uses QUEUE_FLAG_NONROT, which effectively
+ restricts the function of the elevator to block merges. By
+ specifying this flag on the server, the client will not use
+ QUEUE_FLAG_NONROT, meaning the client elevator will perform
+ normal elevator ordering of I/O requests. Note that even when
+ the backing store is on rotating media, it is not normally
+ necessary to specify this flag, as the server's elevator
+ algorithm will be used. This flag is only required where
+ the server will not be using an elevator algorithm or where
+ the elevator algorithm is effectively neutered (e.g. with
+ the sync option set). This option will have no effect unless
+ supported by the client.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
<term><option>sparse_cow</option></term>
<listitem>
<para>Optional; boolean.</para>
</para>
</listitem>
</varlistentry>
+ <varlistentry>
+ <term><option>transactionlog</option></term>
+ <listitem>
+ <para>Optional; string</para>
+ <para>
+ If specified, then this pathname is used to generate a transaction
+ log. A transaction log is a binary file consisting of the requests
+ sent to and the replies received by the server, but excluding any
+ data (so, for a write command, it records the offset and length
+ of the write but not the data written). It is therefore relatively
+ safe to distribute to a third party. Note that the transaction log
+ does not include the negotiation sequence. Transaction logs are
+ mainly useful for debugging. The program
+ <emphasis>nbd-tester-client</emphasis> distributed with the source
+ to this program can reply a transaction log against a server and
+ perform a data integrity test. Note that the transaction log is
+ written to for every client opened. If it is necessary to maintain
+ separate transaction logs for each client, the
+ <emphasis>prerun</emphasis> script should rename the transaction log
+ (which will just have been opened in order to avoid transaction logs
+ overwriting eachother. This action should be race-free.
+ </para>
+ </listitem>
+ </varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>SEE ALSO</title>
- <para>nbd-server (1), nbd-client (8),
- http://nbd.sourceforge.net/roadmap.html</para>
+ <para>nbd-server (1), nbd-client (8)</para>
+
</refsect1>
<refsect1>
[export]
exportname = /export/blkdev
port = 12345
- authfile = @sysconfdir@/nbd-server/allow
+ authfile = $sysconfdir/nbd-server/allow
</programlisting>
- <para>With @sysconfdir@/nbd-server/allow containing the following:</para>
+ <para>With $sysconfdir/nbd-server/allow containing the following:</para>
<programlisting>
127.0.0.1
192.168.0.0/8
projects / nbd.git / blobdiff