`/ Etc / fstab` è usato per rimontare le unità?

Ho un dispositivo installato con Ubuntu 14.04.5 che ha un singolo disco rigido con un file system ext4.

Leggendo il documento Ext4 Filesystem ho appreso che la modalità dati predefinita è orderedche protegge solo i metadati. Nel mio progetto, vogliamo cambiarlo per journalproteggere anche i dati dei file perché la sicurezza dei dati ha un valore più elevato.

La prima cosa che ho provato è stata quella di modificare il /etc/fstabfile. Ho provato a cambiare

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

per

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

aggiungendo data=journalal campo opzione.

Tuttavia, quando riavvio il dispositivo, ho finito con un messaggio di errore che diceva cannot change data mode on remount. Ho controllato dmesge ho visto un messaggio precedente sul montaggio dell'unità con orderedmodalità dati.

Per un tempo imbarazzante, ho pensato che fosse /etc/fstabutilizzato per sovrascrivere le opzioni di montaggio predefinite in modo che le unità vengano montate una sola volta. Ma ora sembra sbagliato: l'unità viene montata utilizzando le opzioni di montaggio predefinite, quindi /etc/fstabviene prelevata per rimontarla.

Le mie domande sono :

• Questo processo di "mount-remout" è il design del sistema? Ho letto la Fstabpagina wiki ma non ho visto che menziona la cosa "mount-remount".
• Se /etc/fstabviene veramente utilizzato per il rimontaggio, in quale fase del processo di avvio viene montata l'unità per la prima volta? È implementato in /etc/init.d? Ho visto alcuni script in /etc/init.dchiamato umountfse umountroot, ma, scremandone il contenuto, non sembrano rilevanti.

Da man ext4:

Dati = {giornale | ordinato | writeback}
              Specifica la modalità journaling per i dati di file. I metadati lo sono sempre
              journal. Per utilizzare modalità diverse da quelle ordinate sul file root
              tem, passa la modalità al kernel come parametro di avvio, ad es. root‐
              flags = data = journal.

Rimuovi data=ordereddalla tua fstab-line e modifica /etc/default/grubinvece. Nel /etc/default/grubcambiare la linea

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

per

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

eseguire sudo update-grube riavviare.

Quando viene utilizzato / etc / fstab

Se esegui sudo strace -e open,openat mount -o remount,rw /vedrai che il comando infatti si apre /etc/fstab. Questo è il comando più comune che vedrai, spesso indicato negli articoli su come lavorare dalla shell di ripristino.

Per citare anche la risposta di sourcejedi (che viene dal mount(8)manuale):

mount -o remount, rw / dir

Dopo questa chiamata, mount legge fstab e unisce queste opzioni con le opzioni dalla riga di comando (-o) . Se non viene trovato alcun mountpoint in fstab, è consentito un rimontaggio con sorgente non specificata.

Tuttavia, ciò non significa che /etc/fstabvenga sempre utilizzato. In particolare, quando si specifica anche il file del dispositivo; riferimento al mount(8)manuale :

La funzionalità di rimontaggio segue il modo standard in cui il comando mount funziona con le opzioni di fstab. Significa che il comando mount non legge fstab (o mtab) solo quando un dispositivo e una directory sono completamente specificati.

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

Dopo questa chiamata, tutte le vecchie opzioni di mount vengono sostituite e le cose arbitrarie di fstab vengono ignorate , ad eccezione dell'opzione loop = che viene generata internamente e gestita dal comando mount.

Questo ha senso, dal momento che /dirpotrebbe essere arbitrario: rimontare un dispositivo su un mountpoint diverso.

Non /etc/fstabsi fa nemmeno riferimento a quando si monta il /filesystem all'avvio il kernel non ne sa nulla /etc/fstab. Per citare la risposta di psusi :

Alla fine è arrivato il boot loader e potrebbe passare una riga di comando al kernel. Se l'argomento root = veniva passato, ciò diceva al kernel dove si trovava root fs invece del valore incorporato. I driver dovevano accedere a quelli che dovevano ancora essere integrati nel kernel

...

Finalmente oggi abbiamo gli initramfs. Questo è simile a initrd, ma invece di essere un'immagine di filesystem compressa caricata in un ramdisk, è un archivio compresso di cpio. Un tmpfs viene montato come root e l'archivio viene estratto lì. Invece di usare pivot_root, che era considerato un hack sporco, gli script di avvio di initramfs montano la radice reale in / root, eliminano tutti i file nella radice tmpfs, quindi eseguono il chroot in / root e exec / sbin / init

File system che non richiedono fstab

Si noti inoltre che il kernel Linux ha altri filesystem che risiedono in memoria - questi non sono normalmente disponibili per gli utenti, alcuni dei quali non hanno affatto un mountpoint, mentre alcuni sono esposti agli utenti. Il kernel non deve fare riferimento /etc/fstaba quelli. Ne è un esempio /proc: si tratta di un filesystem virtuale che espone principalmente informazioni sui processi e alcune cose sull'hardware e sul sistema che dovrebbero essere realmente presenti in /sysun altro filesystem virtuale.