nixos docs: format =)
This commit is contained in:
@@ -3,44 +3,44 @@
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="ch-file-systems">
|
||||
|
||||
<title>File Systems</title>
|
||||
|
||||
<para>You can define file systems using the
|
||||
<option>fileSystems</option> configuration option. For instance, the
|
||||
following definition causes NixOS to mount the Ext4 file system on
|
||||
device <filename>/dev/disk/by-label/data</filename> onto the mount
|
||||
point <filename>/data</filename>:
|
||||
|
||||
<title>File Systems</title>
|
||||
<para>
|
||||
You can define file systems using the <option>fileSystems</option>
|
||||
configuration option. For instance, the following definition causes NixOS to
|
||||
mount the Ext4 file system on device
|
||||
<filename>/dev/disk/by-label/data</filename> onto the mount point
|
||||
<filename>/data</filename>:
|
||||
<programlisting>
|
||||
<xref linkend="opt-fileSystems"/>."/data" =
|
||||
{ device = "/dev/disk/by-label/data";
|
||||
fsType = "ext4";
|
||||
};
|
||||
</programlisting>
|
||||
|
||||
Mount points are created automatically if they don’t already exist.
|
||||
For <option><link linkend="opt-fileSystems._name__.device">device</link></option>, it’s best to use the topology-independent
|
||||
device aliases in <filename>/dev/disk/by-label</filename> and
|
||||
<filename>/dev/disk/by-uuid</filename>, as these don’t change if the
|
||||
topology changes (e.g. if a disk is moved to another IDE
|
||||
controller).</para>
|
||||
|
||||
<para>You can usually omit the file system type
|
||||
(<option><link linkend="opt-fileSystems._name__.fsType">fsType</link></option>), since <command>mount</command> can usually
|
||||
detect the type and load the necessary kernel module automatically.
|
||||
However, if the file system is needed at early boot (in the initial
|
||||
ramdisk) and is not <literal>ext2</literal>, <literal>ext3</literal>
|
||||
or <literal>ext4</literal>, then it’s best to specify
|
||||
<option>fsType</option> to ensure that the kernel module is
|
||||
available.</para>
|
||||
|
||||
<note><para>System startup will fail if any of the filesystems fails to mount,
|
||||
dropping you to the emergency shell.
|
||||
You can make a mount asynchronous and non-critical by adding
|
||||
<literal><link linkend="opt-fileSystems._name__.options">options</link> = [ "nofail" ];</literal>.
|
||||
</para></note>
|
||||
|
||||
<xi:include href="luks-file-systems.xml" />
|
||||
|
||||
Mount points are created automatically if they don’t already exist. For
|
||||
<option><link linkend="opt-fileSystems._name__.device">device</link></option>,
|
||||
it’s best to use the topology-independent device aliases in
|
||||
<filename>/dev/disk/by-label</filename> and
|
||||
<filename>/dev/disk/by-uuid</filename>, as these don’t change if the
|
||||
topology changes (e.g. if a disk is moved to another IDE controller).
|
||||
</para>
|
||||
<para>
|
||||
You can usually omit the file system type
|
||||
(<option><link linkend="opt-fileSystems._name__.fsType">fsType</link></option>),
|
||||
since <command>mount</command> can usually detect the type and load the
|
||||
necessary kernel module automatically. However, if the file system is needed
|
||||
at early boot (in the initial ramdisk) and is not <literal>ext2</literal>,
|
||||
<literal>ext3</literal> or <literal>ext4</literal>, then it’s best to
|
||||
specify <option>fsType</option> to ensure that the kernel module is
|
||||
available.
|
||||
</para>
|
||||
<note>
|
||||
<para>
|
||||
System startup will fail if any of the filesystems fails to mount, dropping
|
||||
you to the emergency shell. You can make a mount asynchronous and
|
||||
non-critical by adding
|
||||
<literal><link linkend="opt-fileSystems._name__.options">options</link> = [
|
||||
"nofail" ];</literal>.
|
||||
</para>
|
||||
</note>
|
||||
<xi:include href="luks-file-systems.xml" />
|
||||
</chapter>
|
||||
|
||||
Reference in New Issue
Block a user