Próximo: Dispositivos mapeados, Anterior: operating-system
Reference, Acima: Configuração do sistema [Conteúdo][Índice]
The list of file systems to be mounted is specified in the
file-systems
field of the operating system declaration (veja Usando o sistema de configuração). Each file system is declared using the
file-system
form, like this:
(file-system
(mount-point "/home")
(device "/dev/sda3")
(type "ext4"))
As usual, some of the fields are mandatory—those shown in the example above—while others can be omitted. These are described below.
Objects of this type represent file systems to be mounted. They contain the following members:
tipo
This is a string specifying the type of the file system—e.g.,
"ext4"
.
mount-point
This designates the place where the file system is to be mounted.
device
This names the “source” of the file system. It can be one of three things: a file system label, a file system UUID, or the name of a /dev node. Labels and UUIDs offer a way to refer to file systems without having to hard-code their actual device name29.
File system labels are created using the file-system-label
procedure,
UUIDs are created using uuid
, and /dev nodes are plain
strings. Here’s an example of a file system referred to by its label, as
shown by the e2label
command:
(file-system
(mount-point "/home")
(type "ext4")
(device (file-system-label "my-home")))
UUIDs are converted from their string representation (as shown by the
tune2fs -l
command) using the uuid
form30, like
this:
(file-system
(mount-point "/home")
(type "ext4")
(device (uuid "4dab5feb-d176-45de-b287-9b0a6e4c01cb")))
When the source of a file system is a mapped device (veja Dispositivos mapeados), its device
field must refer to the mapped device
name—e.g., "/dev/mapper/root-partition". This is required so that
the system knows that mounting the file system depends on having the
corresponding device mapping established.
flags
(default: '()
)This is a list of symbols denoting mount flags. Recognized flags include
read-only
, bind-mount
, no-dev
(disallow access to
special files), no-suid
(ignore setuid and setgid bits),
no-atime
(do not update file access times), no-diratime
(likewise for directories only), strict-atime
(update file access
time), lazy-time
(only update time on the in-memory version of the
file inode), no-exec
(disallow program execution), and shared
(make the mount shared). Veja Mount-Unmount-Remount em The GNU C
Library Reference Manual, for more information on these flags.
options
(default: #f
)This is either #f
, or a string denoting mount options passed to the
file system driver. Veja Mount-Unmount-Remount em The GNU C Library
Reference Manual, for details.
Run man 8 mount
for options for various file systems, but beware
that what it lists as file-system-independent “mount options” are in fact
flags, and belong in the flags
field described above.
The file-system-options->alist
and alist->file-system-options
procedures from (gnu system file-systems)
can be used to convert file
system options given as an association list to the string representation,
and vice-versa.
mount?
(default: #t
)This value indicates whether to automatically mount the file system when the
system is brought up. When set to #f
, the file system gets an entry
in /etc/fstab (read by the mount
command) but is not
automatically mounted.
needed-for-boot?
(default: #f
)This Boolean value indicates whether the file system is needed when booting. If that is true, then the file system is mounted when the initial RAM disk (initrd) is loaded. This is always the case, for instance, for the root file system.
check?
(padrão: #t
)This Boolean indicates whether the file system should be checked for errors before being mounted. How and when this happens can be further adjusted with the following options.
skip-check-if-clean?
(default: #t
)When true, this Boolean indicates that a file system check triggered by
check?
may exit early if the file system is marked as “clean”,
meaning that it was previously correctly unmounted and should not contain
errors.
Setting this to false will always force a full consistency check when
check?
is true. This may take a very long time and is not
recommended on healthy systems—in fact, it may reduce reliability!
Conversely, some primitive file systems like fat
do not keep track of
clean shutdowns and will perform a full scan regardless of the value of this
option.
repair
(default: 'preen
)When check?
finds errors, it can (try to) repair them and continue
booting. This option controls when and how to do so.
If false, try not to modify the file system at all. Checking certain file
systems like jfs
may still write to the device to replay the
journal. No repairs will be attempted.
If #t
, try to repair any errors found and assume “yes” to all
questions. This will fix the most errors, but may be risky.
If 'preen
, repair only errors that are safe to fix without human
interaction. What that means is left up to the developers of each file
system and may be equivalent to “none” or “all”.
create-mount-point?
(default: #f
)When true, the mount point is created if it does not exist yet.
mount-may-fail?
(default: #f
)When true, this indicates that mounting this file system can fail but that
should not be considered an error. This is useful in unusual cases; an
example of this is efivarfs
, a file system that can only be mounted
on EFI/UEFI systems.
dependencies
(default: '()
)This is a list of <file-system>
or <mapped-device>
objects
representing file systems that must be mounted or mapped devices that must
be opened before (and unmounted or closed after) this one.
As an example, consider a hierarchy of mounts: /sys/fs/cgroup is a dependency of /sys/fs/cgroup/cpu and /sys/fs/cgroup/memory.
Another example is a file system that depends on a mapped device, for example for an encrypted partition (veja Dispositivos mapeados).
shepherd-requirements
(default: '()
)This is a list of symbols denoting Shepherd requirements that must be met before mounting the file system.
As an example, an NFS file system would typically have a requirement for
networking
.
Typically, file systems are mounted before most other Shepherd services are
started. However, file systems with a non-empty shepherd-requirements field
are mounted after Shepherd services have begun. Any Shepherd service that
depends on a file system with a non-empty shepherd-requirements field must
depend on it directly and not on the generic symbol file-systems
.
This procedure returns an opaque file system label from str, a string:
(file-system-label "home") ⇒ #<file-system-label "home">
File system labels are used to refer to file systems by label rather than by device name. See above for examples.
The (gnu system file-systems)
exports the following useful variables.
These are essential file systems that are required on normal systems, such
as %pseudo-terminal-file-system
and %immutable-store
(see
below). Operating system declarations should always contain at least these.
This is the file system to be mounted as /dev/pts. It supports
pseudo-terminals created via openpty
and similar functions
(veja Pseudo-Terminals em The GNU C Library Reference Manual).
Pseudo-terminals are used by terminal emulators such as xterm
.
This file system is mounted as /dev/shm and is used to support memory
sharing across processes (veja shm_open
em The GNU C Library Reference Manual).
This file system performs a read-only “bind mount” of /gnu/store,
making it read-only for all the users including root
. This prevents
against accidental modification by software running as root
or by
system administrators.
The daemon itself is still able to write to the store: it remounts it read-write in its own “name space.”
The binfmt_misc
file system, which allows handling of arbitrary
executable file types to be delegated to user space. This requires the
binfmt.ko
kernel module to be loaded.
The fusectl
file system, which allows unprivileged users to mount and
unmount user-space FUSE file systems. This requires the fuse.ko
kernel module to be loaded.
The (gnu system uuid)
module provides tools to deal with file system
“unique identifiers” (UUIDs).
Return an opaque UUID (unique identifier) object of the given type (a symbol) by parsing str (a string):
(uuid "4dab5feb-d176-45de-b287-9b0a6e4c01cb") ⇒ #<<uuid> type: dce bv: …> (uuid "1234-ABCD" 'fat) ⇒ #<<uuid> type: fat bv: …>
type may be one of dce
, iso9660
, fat
,
ntfs
, or one of the commonly found synonyms for these.
UUIDs are another way to unambiguously refer to file systems in operating system configuration. See the examples above.
Note that, while it is tempting to use /dev/disk/by-uuid and similar device names to achieve the same result, this is not recommended: These special device nodes are created by the udev daemon and may be unavailable at the time the device is mounted.
The
uuid
form expects 16-byte UUIDs as defined in
RFC 4122. This is the form
of UUID used by the ext2 family of file systems and others, but it is
different from “UUIDs” found in FAT file systems, for instance.
Próximo: Dispositivos mapeados, Anterior: operating-system
Reference, Acima: Configuração do sistema [Conteúdo][Índice]