Wird `/ etc / fstab` verwendet, um Laufwerke erneut bereitzustellen?

Ich habe ein Gerät mit Ubuntu 14.04.5 installiert, das eine einzelne Festplatte mit einem ext4-Dateisystem hat.

Beim Lesen des Dokuments Ext4 Filesystem habe ich erfahren, dass der Standarddatenmodus orderednur die Metadaten schützt. In meinem Projekt möchten wir es ändern, journalum auch Dateidaten zu schützen, da die Datensicherheit von höherem Wert ist.

Als erstes habe ich versucht, die /etc/fstabDatei zu ändern . Ich habe versucht mich zu ändern

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

zu

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

durch Anhängen data=journalan das Optionsfeld.

Beim Neustart des Geräts wurde jedoch eine Fehlermeldung angezeigt cannot change data mode on remount. Ich habe das überprüft dmesgund eine frühere Meldung zum Mounten des Laufwerks im orderedDatenmodus gesehen.

Für eine peinlich lange Zeit dachte ich, /etc/fstabwird verwendet, um die Standard-Montageoptionen zu überschreiben, so dass die Laufwerke nur einmal gemountet werden. Aber jetzt sieht es falsch aus: Das Laufwerk wird mit seinen Standard-Mount-Optionen gemountet und dann /etc/fstabzum erneuten Mounten aufgenommen.

Meine Fragen sind :

• Ist dieser "Mount-Remout" -Prozess das Design des Systems? Ich habe die FstabWiki-Seite gelesen , aber nicht gesehen, dass sie das "Mount-Remount" -Ding erwähnt.
• Wenn /etc/fstabes wirklich für die erneute Bereitstellung verwendet wird, in welchem ​​Schritt des Startvorgangs wird das Laufwerk zum ersten Mal bereitgestellt? Ist es implementiert in /etc/init.d? Ich habe einige Skripte in sehen /etc/init.dgenannt umountfsund umountroot, aber, Skimming deren Inhalt, sie sehen nicht relevant.

Von man ext4:

data = {journal | ordered | writeback}
              Gibt den Journalmodus für Dateidaten an. Metadaten sind immer
              aufgezeichnet. Andere als die auf der Root-Datei bestellten Modi verwenden
              Übergeben Sie den Modus als Boot-Parameter an den Kernel, z. B. root‐
              flags = data = journal.

Entfernen Sie data=orderedaus Ihrer fstab-Zeile und bearbeiten Sie /etc/default/grubstattdessen. In /etc/default/grubÄnderung der Linie

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

zu

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

ausführen sudo update-grubund neu starten .

Wenn / etc / fstab verwendet wird

Wenn Sie ausführen, werden sudo strace -e open,openat mount -o remount,rw /Sie feststellen, dass der Befehl tatsächlich geöffnet wird /etc/fstab. Dies ist der häufigste Befehl, auf den häufig in Artikeln zum Arbeiten mit der Wiederherstellungsshell verwiesen wird.

Um auch die Antwort von sourcejedi zu zitieren (die aus dem mount(8)Handbuch stammt ):

mount -o remount, rw / dir

Nach diesem Aufruf liest mount fstab und führt diese Optionen mit den Optionen in der Befehlszeile (-o) zusammen . Wenn in fstab kein Mountpoint gefunden wird, ist ein Remount mit nicht angegebener Quelle zulässig.

Dies bedeutet jedoch nicht, dass dies /etc/fstabimmer verwendet wird. Insbesondere, wenn Sie auch die Gerätedatei angeben; Verweis auf das mount(8)Handbuch :

Die Remount-Funktion folgt der Standardmethode, mit der der Befehl mount mit Optionen von fstab funktioniert. Dies bedeutet, dass der Befehl mount fstab (oder mtab) nur dann nicht liest, wenn ein Gerät und ein Verzeichnis vollständig angegeben sind.

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

Nach diesem Aufruf werden alle alten Mount-Optionen ersetzt und beliebige Inhalte von fstab werden ignoriert , mit Ausnahme der Option loop =, die intern vom Befehl mount generiert und verwaltet wird.

Dies ist sinnvoll, da /dires beliebig sein kann, ein Gerät erneut an einem anderen Mountpoint zu montieren.

Auf das /etc/fstabwird auch nicht verwiesen, wenn der /Kernel beim Mounten des Dateisystems beim Booten nichts weiß /etc/fstab. Um die Antwort von psusi zu zitieren :

Schließlich kamen Bootloader und konnten eine Befehlszeile an den Kernel übergeben. Wenn das Argument root = übergeben wurde, wurde dem Kernel mitgeteilt, wo sich das Root-fs anstelle des integrierten Werts befindet. Die Treiber, auf die zugegriffen werden musste, mussten noch in den Kernel integriert werden

...

Endlich haben wir heute die initramfs. Dies ähnelt dem initrd, ist jedoch kein komprimiertes Dateisystem-Image, das auf eine Ramdisk geladen wird, sondern ein komprimiertes cpio-Archiv. Ein tmpfs wird als Root gemountet und das Archiv dort extrahiert. Anstatt pivot_root zu verwenden, das als Dirty Hack angesehen wurde, mounten die initramfs-Boot-Skripte das echte Root-Verzeichnis in / root, löschen alle Dateien im tmpfs-Stammverzeichnis, chrootieren in / root und exec / sbin / init

Dateisysteme, die keine fstab benötigen

Beachten Sie auch, dass der Linux-Kernel über andere Dateisysteme verfügt, die sich im Speicher befinden. Diese stehen Benutzern normalerweise nicht zur Verfügung, von denen einige überhaupt keinen Mountpoint haben, während andere den Benutzern zugänglich sind. Der Kernel muss /etc/fstabfür diese nicht referenzieren . Ein Beispiel dafür ist /proc- es ist ein virtuelles Dateisystem, das hauptsächlich Informationen über Prozesse und einige Dinge über Hardware und System enthält, in denen es sich wirklich befinden sollte /sys- ein anderes virtuelles Dateisystem.