[linux-l] größtes RAID: bestes FS?

Volker Grabsch vog at notjusthosting.com
Do Feb 5 18:20:34 CET 2009


Ralph Angenendt <ralph at strg-alt-entf.org> schrieb:
> Lutz Willek wrote:
>
> > Daneben gibt es noch ein ganz praktisches Problem: wie lange dauert wohl
> > ein ungeplanter Dateisystemcheck bei ext3 und 4 TB Partitionsgröße?
> > [ ]  lange
> > [ ]  sehr lange
> > [ ]  unheimlich lange
> > [x]  länger als mir lieb ist
> 
> Das ist bei xfs auch nicht anders, außer dass xfs_check nebenbei
> ziemlich viel Speicher benötigt.
> [...]
> Wo du gerade Red Hat ansprichst: Die setzen beim fsck max-mount-counts
> auf -1 und interval-between-checks auf 0. 

Ich benutze Debian, die handhaben das per Default anders, aber ich
setze für jedes neue ext3-Dateisystem sofort "tune2fs -i0 -c0 ..."
Denn ein Dateisystem-Check kommt grundsätzlich immer dann, wenn man
ihn am allerwenigsten gebrauchen kann, und wenn er am allerwenigsten
nützt. Der "Schaden" durch sinnlose enorme Wartezeiten beim seltenen
Reboot ist meiner Erfahrung nach wesentlich größer als die Gefahr
eines inkonsistenten Dateisystems.

Das gilt übrigens für Laptop wie für Server gleichermaßen: Mein
Laptop läuft normalerweise Monate lang ohne Reboot. Gut, die meiste
Zeit davon im Suspend-Modus, aber eben ohne Reboot. Und die Server
laufen ebenfalls "ewig" - bis zum nächsten Kernel-Security-Patch.

Wenn dann ausnahmsweise ein Reboot fällig wird, sei es wegen einem
Kernel-Patch oder wegen einem Stromausfall, dann ist bis dahin der
'interval-between-checks' längst abgelaufen. Das heißt, ein kleiner
Reboot, bei dem es wichtig ist, dass die Ausfallzeit minimal ist,
wird "dank" fsck regelmäßig zur Farce.

Der automatische fsck-Aufruf beim Rooten mag historisch sinnvoll
gewesen sein, damals, als es noch keine Journallig-Dateisysteme
gab. Aber heutzutage richtet das mehr Schaden an, als es nützt.


Gruß,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR



Mehr Informationen über die Mailingliste linux-l