`/ Etc / fstab` est-il utilisé pour remonter les lecteurs?

J'ai un appareil installé avec Ubuntu 14.04.5 qui a un seul disque dur avec un système de fichiers ext4.

En lisant le document Système de fichiers Ext4, j'ai appris que le mode de données par défaut est celui orderedqui protège uniquement les métadonnées. Dans mon projet, nous voulons le changer pour journalprotéger également les données des fichiers car la sécurité des données est de plus grande valeur.

La première chose que j'ai essayée a été de modifier le /etc/fstabfichier. J'ai essayé de changer

UUID=<UUID> / ext4 errors=remount-ro 0 1

à

UUID=<UUID> / ext4 errors=remount-ro,data=journal 0 1

en ajoutant data=journalau champ d'option.

Cependant, lorsque je redémarre l'appareil, je me suis retrouvé avec un message d'erreur disant cannot change data mode on remount. J'ai vérifié le dmesget j'ai vu un message précédent sur le montage du lecteur en orderedmode données.

Pendant une longue période embarrassante, je pensais que c'était /etc/fstabutilisé pour remplacer les options de montage par défaut afin que les disques ne soient montés qu'une seule fois. Mais maintenant, cela semble faux: le lecteur est monté en utilisant ses options de montage par défaut, puis /etc/fstabest ramassé pour le remonter.

Mes questions sont :

• Ce processus de "montage-rappel" est-il la conception du système? J'ai lu la Fstabpage wiki mais je n'ai pas vu qu'elle mentionne la chose "mount-remount".
• Si /etc/fstabest vraiment utilisé pour le remontage, à quelle étape du processus de démarrage le disque est-il monté pour la première fois? Est-il implémenté en /etc/init.d? J'ai vu certains scripts dans /etc/init.dappelés umountfset umountroot, mais, en parcourant leur contenu, ils ne semblent pas pertinents.

De man ext4:

data = {journal | commandé | réécriture}
              Spécifie le mode de journalisation des données de fichier. Les métadonnées sont toujours
              journalisé. Pour utiliser des modes autres que ceux commandés sur le système de fichiers racine
              tem, passez le mode au noyau comme paramètre de démarrage, par exemple root
              flags = data = journal.

Supprimez data=orderedde votre ligne fstab et modifiez à la /etc/default/grubplace. En /etc/default/grubchanger la ligne

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

à

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash root‐flags=data=journal"

exécuter sudo update-grubet redémarrer.

Lorsque / etc / fstab est utilisé

Si vous exécutez, sudo strace -e open,openat mount -o remount,rw /vous verrez que la commande s'ouvre en fait /etc/fstab. Il s'agit de la commande la plus courante que vous verrez, souvent référencée dans des articles sur le travail à partir du shell de récupération.

Pour citer également la réponse de sourcejedi (qui vient du mount(8)manuel):

mount -o remount, rw / dir

Après cet appel, mount lit fstab et fusionne ces options avec les options de la ligne de commande (-o) . Si aucun point de montage n'est trouvé dans fstab, un remontage avec une source non spécifiée est autorisé.

Cependant, cela ne signifie pas qu'il /etc/fstabest toujours utilisé. En particulier, lorsque vous spécifiez également le fichier de périphérique; référence au mount(8)manuel :

La fonctionnalité de remontage suit la manière standard dont la commande mount fonctionne avec les options de fstab. Cela signifie que la commande mount ne lit pas fstab (ou mtab) uniquement lorsqu'un périphérique et dir sont entièrement spécifiés.

mount -o remount, rw / dev / foo / dir

Après cet appel, toutes les anciennes options de montage sont remplacées et les éléments arbitraires de fstab sont ignorés , à l'exception de l'option loop = qui est générée en interne et maintenue par la commande mount.

Cela a du sens, car cela /dirpourrait être arbitraire - remonter un périphérique sur un point de montage différent.

Le /etc/fstabn'est pas non plus référencé lorsque le montage du /système de fichiers au moment du démarrage du noyau ne sait rien /etc/fstab. Pour citer la réponse de psusi :

Finalement, les chargeurs de démarrage sont arrivés et pouvaient passer une ligne de commande au noyau. Si l'argument root = a été passé, cela a indiqué au noyau où se trouvait la racine fs au lieu de la valeur intégrée. Les pilotes nécessaires à l'accès devaient encore être intégrés au noyau

...

Enfin, aujourd'hui, nous avons les initramfs. C'est semblable à l'initrd, mais au lieu d'être une image de système de fichiers compressée qui est chargée dans un disque virtuel, c'est une archive cpio compressée. Un tmpfs est monté en tant que racine et l'archive y est extraite. Au lieu d'utiliser pivot_root, qui était considéré comme un hack sale, les scripts de démarrage initramfs montent la vraie racine dans / root, suppriment tous les fichiers dans la racine tmpfs, puis chrootent dans / root et exec / sbin / init

Systèmes de fichiers qui n'ont pas besoin de fstab

Notez également que le noyau Linux a d' autres systèmes de fichiers qui résident en mémoire - ceux-ci ne sont pas disponibles normalement pour les utilisateurs, dont certains n'ont pas du tout de point de montage, tandis que certains sont exposés aux utilisateurs. Le noyau n'a pas à faire référence /etc/fstabà ceux-ci. Un exemple de cela est /proc- c'est un système de fichiers virtuel qui expose principalement des informations sur les processus, et certaines choses sur le matériel et le système qui devraient vraiment être dans /sys- un autre système de fichiers virtuel.