Suivant: Périphériques mappés, Précédent: Référence de operating-system
, Monter: Configuration du système [Table des matières][Index]
La liste des systèmes de fichiers à monter est spécifiée dans le champ
file-systems
de la déclaration de système d’exploitation
(voir Utiliser le système de configuration). Chaque système de fichier est
déclaré avec la forme file-system
, comme ceci :
(file-system
(mount-point "/home")
(device "/dev/sda3")
(type "ext4"))
Comme d’habitude, certains de ces champs sont obligatoire — comme le montre l’exemple au-dessus — alors que d’autres peuvent être omis. Ils sont décrits plus bas.
Les objets de ce type représentent des systèmes de fichiers à monter. Ils contiennent les membres suivants :
type
C’est une chaîne de caractères spécifiant le type du système de fichier —
p. ex. "ext4"
.
mount-point
Désigne l’emplacement où le système de fichier sera monté.
device
Ce champ nomme le système de fichier « source ». il peut être l’une de ces trois choses : une étiquette de système de fichiers, un UUID de système de fichier ou le nom d’un nœud dans /dev. Les étiquettes et les UUID offrent une manière de se référer à des systèmes de fichiers sans avoir à coder en dur le nom de périphérique30.
Les étiquettes de systèmes de fichiers sont crées avec la procédure
file-system-label
, les UUID avec uuid
et les nœuds de
/dev sont de simples chaînes de caractères. Voici un exemple d’un
système de fichiers référencé par son étiquette, donnée par la commande
e2label
:
(file-system
(mount-point "/home")
(type "ext4")
(device (file-system-label "my-home")))
Les UUID sont convertis à partir de leur représentation en chaîne de
caractères (montrée par la commande tune2fs -l
) en utilisant la
forme uuid
31,
comme ceci :
(file-system
(mount-point "/home")
(type "ext4")
(device (uuid "4dab5feb-d176-45de-b287-9b0a6e4c01cb")))
Lorsque la source d’un système de fichiers est un périphérique mappé
(voir Périphériques mappés), sont champ device
doit se référer au
nom du périphérique mappé — p. ex. "/dev/mapper/root-partition".
Cela est requis pour que le système sache que monter ce système de fichier
dépend de la présence du périphérique mappé correspondant.
flags
(par défaut : '()
)C’est une liste de symboles qui désignent des drapeaux de montage. Les
drapeaux reconnus sont read-only
, bind-mount
, no-dev
(interdit l’accès aux fichiers spéciaux), no-suid
(ignore les bits
setuid et setgid), no-atime
(ne met pas à jour les heures d’accès aux
fichiers), no-diratime
(pareil mais pour les répertoires uniquement),
strict-atime
(met à jour les heures d’accès aux fichiers),
lazy-time
(ne met à jour les heures que dans la version mémoire des
inœuds de fichiers), no-exec
(interdit l’exécution de programmes), et
shared
(partage le montage). Voir Mount-Unmount-Remount dans The GNU C Library Reference Manual, pour plus d’informations sur ces
drapeaux.
options
(par défaut : #f
)C’est soit #f
, soit une chaine qui dénote les options de montage
passées au pilote de système de fichiers. Voir Mount-Unmount-Remount dans le manuel de référence de la bibliothèque C de GNU pour plus de
détails.
Lancez man 8 mount
pour voir les options des divers systèmes de
fichiers, mais sachez que les « options de montage » indépendantes du
système de fichiers sont en fait des drapeaux, et appartiennent au champ
flags
décrit plus haut.
Les procédures file-system-options->alist
et
alist->file-system-options
de (gnu system file-systems)
peuvent être utilisées pour convertir des options de systèmes de fichiers
données sous forme de liste d’association en représentation de chaîne de
caractères, et vice-versa.
mount?
(par défaut : #t
)Cette valeur indique s’il faut monter automatiquement le système de fichier
au démarrage du système. Lorsque la valeur est #f
, le système de
fichier reçoit une entrée dans /etc/fstab (lue par la commande
mount
) mais n’est pas monté automatiquement.
needed-for-boot?
(par défaut : #f
)Cette valeur booléenne indique si le système de fichier est nécessaire au démarrage. Si c’est vrai alors le système de fichier est monté au chargement du disque de RAM initial. C’est toujours le cas par exemple du système de fichiers racine.
check?
(par défaut : #t
)Cette valeur booléenne indique si le système de fichier devrait être vérifié avant de le monter. Comment et quand cela se produit peut être réglé plus en détail avec les options suivantes.
skip-check-if-clean?
(par défaut : #t
)Lorsqu’il a la valeur vrai, ce booléen indique qu’une vérification de
système de fichier initiée par check?
peut terminer prématurément si
le système de fichier est marqué comme « propre », ce qui signifie qu’il a
préalablement été démonté correctement and ne devrait contenir aucune
erreur.
Lui affecter la valeur faux imposera toujours une vérification de cohérence
complète si check?
est à vrai. Cela peut prendre très longtemps et
n’est pas recommandé sur des systèmes sains—en fait, cela pourrait même
réduire la fiabilité !
À l’inverse, certains systèmes de fichiers primitifs comme fat
ne
gardent pas trace des arrêts propres et exécuteront une vérification
complète sans tenir compte de la valeur de cette option.
repair
(par défaut : 'preen
)Quand check?
trouve des erreurs, il peut (essayer de) les réparer
pour poursuivre le démarrage. Cette option contrôle dans quel cas et de
quelle manière appliquer cette stratégie.
À la valeur faux, il essayera de pas modifier le système de fichier du
tout. Vérifier certains systèmes de fichiers comme jfs
peut quand
même provoquer des écritures sur le périphérique pour rejouer le
journal. Aucune réparation ne sera tentée.
Si la valeur #t
est renseignée, il essayera de récupérer toute erreur
qu’il trouvera et supposera qu’il peut répondre « oui » à toutes les
questions. Cela corrigera la plupart des erreurs, mais peut s’avérer risqué.
Si elle vaut 'preen
, il ne réparera que les erreurs qui peuvent être
corrigées sans risque en l’absence d’intervention humaine. Ce que cela
signifie est laissé à l’appréciation des personnes qui développent chaque
système de fichier et peut être équivalent à « aucune » ou « toutes ».
create-mount-point?
(par défaut : #f
)Lorsque cette valeur est vraie, le point de montage est créé s’il n’existe pas déjà.
mount-may-fail?
(par défaut : #t
)Lorsque cela est vrai, indique que le montage de ce système de fichiers peut
échouer, mais cela ne doit pas être considéré comme une erreur. Ceci est
utile dans des cas inhabituels ; un exemple de ceci est efivarfs
, un
système de fichiers qui ne peut être monté que sur des systèmes EFI/UEFI.
dependencies
(par défaut : '()
)C’est une liste d’objets <file-system>
ou <mapped-device>
qui
représentent les systèmes de fichiers qui doivent être montés ou les
périphériques mappés qui doivent être ouverts avant (et monté ou fermés
après) celui-ci.
Par exemple, considérons une hiérarchie de montage : /sys/fs/cgroup est une dépendance de /sys/fs/cgroup/cpu et /sys/fs/cgroup/memory.
Un autre exemple est un système de fichier qui dépend d’un périphérique mappé, par exemple pour une partition chiffrée (voir Périphériques mappés).
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
.
Cette procédure renvoie un label de système de fichiers opaque à partir de str, une chaîne de caractères :
(file-system-label "home") ⇒ #<file-system-label "home">
Les étiquettes de systèmes de fichiers sont utilisées pour faire référence aux systèmes de fichiers par étiquette plutôt que par nom de dispositif. Voir ci-dessus pour des exemples.
Le module (gnu system file-systems)
exporte les variables utiles
suivantes.
Ce sont les systèmes de fichiers essentiels qui sont requis sur les systèmes
normaux, comme %pseudo-terminal-file-system
et
%immutable-store
(voir plus bas). Les déclarations de systèmes
d’exploitation devraient au moins les contenir.
C’est le système de fichier monté sur /dev/pts. Il supporte les
pseudo-terminaux créés via openpty
et les fonctions similaires
(voir Pseudo-Terminals dans The GNU C Library Reference Manual). Les
pseudo-terminaux sont utilisés par les émulateurs de terminaux comme
xterm
.
Ce système de fichier est monté dans /dev/shm et est utilisé pour le
partage de mémoire entre processus (voir shm_open
dans The GNU C Library Reference Manual).
Ce système de fichiers effectue un « montage lié » en lecture-seule de
/gnu/store, ce qui en fait un répertoire en lecture-seule pour tous
les utilisateurs dont root
. Cela évite que des logiciels qui
tournent en root
ou des administrateurs systèmes ne modifient
accidentellement le dépôt.
Le démon lui-même est toujours capable d’écrire dans le dépôt : il est remonté en lecture-écriture dans son propre « espace de nom ».
Le système de fichiers binfmt_misc
, qui permet de gérer n’importe
quel type de fichiers exécutables à déléguer en espace utilisateur. Cela
demande que le module du noyau binfmt.ko
soit chargé.
Le système de fichiers fusectl
, qui permet à des utilisateurs non
privilégiés de monter et de démonter des systèmes de fichiers FUSE en espace
utilisateur. Cela requiert que le module du noyau fuse.ko
soit
chargé.
Le module (gnu system uuid)
fournit les outils pour traiter les «
identifiants uniques » de système de fichier (UUIDs).
Renvoie un objet UUID (identifiant unique) opaque du type donné (un symbole) en analysant str (une chaîne) :
(uuid "4dab5feb-d176-45de-b287-9b0a6e4c01cb") ⇒ #<uuid> type: dce bv: …> (uuid "1234-ABCD" 'fat) ⇒ #<uuid> type: fat bv: …>
type peut être l’un des codes suivants : dce
, iso9660
,
fat
, ntfs
, ou l’un des synonymes les plus courants.
Les UUIDs sont un autre moyen de faire référence sans ambiguïté aux systèmes de fichiers dans la configuration du système d’exploitation. Voir les exemples ci-dessus.
Remarquez que, s’il est tentant d’utiliser /dev/disk/by-uuid et autres chemins similaires pour obtenir le même résultat, ce n’est pas recommandé : ces nœuds de périphériques spéciaux sont créés par le démon udev et peuvent ne pas être disponibles au moment de monter le périphérique.
La forme uuid
s’attend à des UUID sur 16
octets définis dans la RFC 4122. C’est la forme des UUID utilisées par la famille de
systèmes de fichiers ext2 et d’autres, mais ce n’est pas le même type d’UUID
que ceux qui se trouvent sur les systèmes de fichiers FAT par exemple
Suivant: Périphériques mappés, Précédent: Référence de operating-system
, Monter: Configuration du système [Table des matières][Index]