Ich habe ein großes, häufig gelesenes ext3-Dateisystem, das schreibgeschützt auf einem System gemountet ist, dessen Stromzufuhr im Allgemeinen etwa 2–3 Mal pro Tag unterbrochen wird.
Da das Gerät normalerweise durch Unterbrechen der Stromversorgung ausgeschaltet wird, wird fsck beim Booten auf diesem Dateisystem ausgeführt. Für diese Anwendung sind jedoch schnelle Bootzeiten (auf die Sekunde genau) wichtig.
Ich kann die Bootzeitprüfungen des Dateisystems in fstab deaktivieren, aber meine Frage ist, ist das sicher? Angesichts der Tatsache, dass das Dateisystem schreibgeschützt gemountet, aber nie richtig unmountet wird, gibt esbeliebigBesteht das Risiko, dass sich über einen langen Zeitraum hinweg Beschädigungen des Dateisystems anhäufen, wenn ich die Überprüfung beim Systemstart deaktiviere?
Antwort1
Aus der mountManpage:
-r, --read-only
Mount the filesystem read-only. A synonym is -o ro.
Note that, depending on the filesystem type, state and kernel
behavior, the system may still write to the device. For example,
Ext3 or ext4 will replay its journal if the filesystem is dirty.
To prevent this kind of write access, you may want to mount ext3
or ext4 filesystem with "ro,noload" mount options or set the
block device to read-only mode, see command blockdev(8).
Falls ro,noloaddies nicht ausreicht, ist mir keine Möglichkeit bekannt, mit einem bloßen fstab-Eintrag ein schreibgeschütztes Gerät einzurichten. Möglicherweise müssen Sie vor dem Einhängen Ihres Dateisystems auf andere Weise blockdev --setroein schreibgeschütztes Loop-Gerät () aufrufen oder erstellen .losetup --read-only
Wenn Sie es wirklich schreibgeschützt machen, wird es nicht einmal wissen, dass es gemountet wurde. Somit sind keine Updates des Mount-Zählers und kein erzwungenes Fsck und vor allem keine Beschädigung möglich, solange nie etwas auf das Gerät geschrieben wird ...
Antwort2
Aus der tune2fsManpage:
-c max-mount-counts
Adjust the number of mounts after which the filesystem will be checked by e2fsck(8). If max-mount-counts is 0 or -1, the number
of times the filesystem is mounted will be disregarded by e2fsck(8) and the kernel.
Staggering the mount-counts at which filesystems are forcibly checked will avoid all filesystems being checked at one time when
using journaled filesystems.
You should strongly consider the consequences of disabling mount-count-dependent checking entirely. Bad disk drives, cables,
memory, and kernel bugs could all corrupt a filesystem without marking the filesystem dirty or in error. If you are using jour-
naling on your filesystem, your filesystem will never be marked dirty, so it will not normally be checked. A filesystem error
detected by the kernel will still force an fsck on the next reboot, but it may already be too late to prevent data loss at that
point.
See also the -i option for time-dependent checking.
Und:
-i interval-between-checks[d|m|w]
Adjust the maximal time between two filesystem checks. No postfix or d result in days, m in months, and w in weeks. A value of
zero will disable the time-dependent checking.
It is strongly recommended that either -c (mount-count-dependent) or -i (time-dependent) checking be enabled to force periodic
full e2fsck(8) checking of the filesystem. Failure to do so may lead to filesystem corruption due to bad disks, cables, memory,
or kernel bugs to go unnoticed until they cause data loss or corruption.
Sie können also beide auf Null setzen, was die automatischen fsck's deaktivieren sollte (vorausgesetzt SieGenau genommenmöchte das aber tun).
Antwort3
Ich lasse meine andere Antwort aus historischen und kontextuellen Gründen stehen, aber beim erneuten Lesen sehe ich Ihre eigentliche Frage: Ja, Sie wollen immer nochletztlichführen Sie einen aus fsck. Alle Festplatten haben eine begrenzte Lebensdauer und fsckordnen fehlerhafte Sektoren einem Inode/einer Liste mit „fehlerhaften Blöcken“ zu, sodass sie von keinen neuen Dateien verwendet werden.
Der schreibgeschützte Modus (und die von noloadFrotschutz beschriebenen Aktionen) trägt dazu bei, Konsistenzprobleme aufgrund von Dienstunterbrechungen zu vermeiden. Allerdings müssen Sie dennoch damit rechnen, dass Ihre Hardware einfach den Geist aufgibt.