|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
 |
|
|
|
Von Anonymer Feigling am Sunday 27. July, 14:28 MES (#1)
|
|
|
|
|
Jetzt muss es nur noch so robust sein wie ext2/3.
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Sunday 27. July, 16:17 MES (#4)
|
|
|
|
|
Ich setze sowohl reiserfs3 als auch ext3 ein und hatte noch mit keinem Probleme
|
|
|
|
|
|
|
|
|
|
|
|
|
Kann ich nur bestätigen.
XFS hingegen macht bei Hochlast leicht mal schlapp.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Sunday 27. July, 21:05 MES (#11)
|
|
|
|
|
Toll... Ext3 hat mir heute Nachmittag /boot und / zerbröselt... Ich kehre ext den Rücken zu und benutze wieder ReiserFS.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Sunday 27. July, 15:34 MES (#2)
|
|
|
|
|
Die Lust auf dieses Filesystem ist mir nach mehreren
Datenverlusten vergangen. Die Geschwindikeitsvorteile sind mir eigentlich egal, mir ist die Datensicherheit wichitger.
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Sunday 27. July, 15:42 MES (#3)
|
|
|
|
|
ich habe gesehen, dass xfs im 2.6.0-test1 enthalten ist, wird das in der final version stablil benutzbar sein?
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Sunday 27. July, 16:19 MES (#5)
|
|
|
|
|
Von Reiserfs3, Ext3 und XFS ist XFS wohl das instabilste
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Sunday 27. July, 18:17 MES (#6)
|
|
|
|
|
..dicht gefolgt von ext3..
|
|
|
|
|
|
|
|
|
|
|
|
|
Alle Linux-Dateisysteme sind unsicher, es sei
denn, man mountet sie sync oder mit journal sowohl
auf Metadaten als auch auf Nutzdaten.
Bei BSD softupdates kann man async mounten und hat
trotzdem immer konsistente Metadaten, und in der
Regel auch Nutzdaten (in der Anfangszeit nicht).
Allerdings muß man, sowohl bei Linux als auch bei
BSD, den Hardware <i>write cache</i> der Festplatte aus-
schalten, und OpenBSD bietet dazu standardmäßig
nichtmals eine Möglichkeit (FreeBSD hat's wohl im
Bootloader, hab ich mir sagen lassen).
(atactl wd0 writecachedisable in /etc/rc hilft)
Wie man das bei Linux macht, weiß ich leider nicht.
Siehe auch http://www.mckusick.com/ für einen
Vergleich Softupdates ./. Journalling, falls einem
danach ist (*seufz* wird wohl leider wieder einen
Flamewar vom Zaun brechen - ich werde mich mal
nicht dran beteiligen).
--
mirabile, irc.ipv6.eu.freenode.net:6667 {#deutsch,#ccc,#IceWM,#OpenBSD.de,#IPv6,#freenode,...}
|
|
|
|
|
|
|
|
|
|
|
|
|
<ohne gewähr>
irgendjemand hatte mir mal gesagt dass, falls die Stromversorgung einer Festplatte unterbrochen wird, sie noch genug Schwung hat um genügen Strom für sich selber zu produzieren und den cache auf die Platte zu schreiben. Von daher kann der cache eingeschaltet bleiben.
</ohne gewähr>
Generell sind wohl alle Filesysteme irgendwodurch unsicher egal ob Linux, BSD oder M$. Ein Datenverlust kann nie ganz ausgeschlossen werden.
Ein Filesystem, das mich sehr beeindruckt hat ist jenes von BeOS. Das schöne daran war seine Geschwindigkeit und die Robustheit. Nach einem crash dauerte der boot einige wenige Sekunden länger als sonst - die fsck bei ext3 gehen mir ziemlich auf den Wecker...
|
|
|
|
|
|
|
|
|
|
|
|
|
Dass die Festplatte noch genug Strom produziert um den Cache zu schreiben kann ich nicht bestätigen. Es ist aber so, dass auf einer Festplatte bei einigen Dateisystemen nicht immer zusammenhängende Speicherplätze vorhanden sind. Wenn die Festplatte 8MB Cache hat, muss ein sehr langer Teil frei sein. Wenn kein so langer Teil mehr frei ist, muss der Schreib/Lesekopf unter Umständen recht viele Bewegungen machen, was mit der Restenergie aus dem noch vorhandenen Schwung wahrscheinlich nicht gelingt.
Ich bin mir lediglich sicher, dass die Festplatte mit dieser Restenergie den Schreib/Lesekopf noch in die Landing-Zone bringt, um geschriebene Daten beim Transport nicht zu gefährden.
----------------
Eat, Drink, Drum
|
|
|
|
|
|
|
|
|
|
|
|
|
Das deckt sich mit dem, was ich an diversen
Stellen gefunden und gehoert habe.
Und auch bei einer Platte mit "nur" 1 MB Cache
kann es Datenverluste geben, BTDT.
--
mirabile, irc.ipv6.eu.freenode.net:6667 {#deutsch,#ccc,#IceWM,#OpenBSD.de,#IPv6,#freenode,...}
|
|
|
|
|
|
|
|
|
|
|
|
|
Nach einem crash dauerte der boot einige wenige Sekunden länger als sonst - die fsck bei ext3 gehen mir ziemlich auf den Wecker...
äh... fsck bei ext3 dauert lange?
Das kann ich ned bestätigen... selbsbt bei ner 100GB-Partition innerhalb von 4s abgeschlossen nach nem Stromausfall!
Biste sicher, dass die pladde von Anfang an als ext3 gemountet wird? wie lange dauert denn bei dir ein fsck auf ext3?
|
|
|
|
|
|
|
|
|
|
|
|
|
Ein fsck auf ext3 geht mehrere Stunden, das ist schon korrekt. Das Journal Replay braucht wesentlich weniger Zeit (so im Bereich unter 10 Sekunden).
Das Pendant dazu dauert auch bei reiserfs eine Ewigkeit, vorallem bei Platten mit vielen Metadaten (viele kleine Dateien).
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Sunday 27. July, 18:55 MES (#7)
|
|
|
|
|
xfs ist schon laenger in 2.5.x und wird in 2.6 drin bleiben.
panthera
|
|
|
|
|
|
|
|
|
|
|
|
|
Ist mir noch nie passiert.
Bist du sicher, daß nicht die Festplatte ein Problem hatte ?
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Sunday 27. July, 20:30 MES (#10)
|
|
|
|
|
RaiserFS hatee ne Zeit lang probleme mit Festpaltten, die mehr als 90% gefüllt waren.
|
|
|
|
|
|
|
|
|
|
|
|
|
Auf allen der beiden ide-Platten war ext3 (plus vfat und ntfs - bei einem der beiden Rechner wo das passierte) und bei jedem größeren Datenzugriff gabs nen Kernel-Panik; die ext3 Partitionen auf der einen Platte als ext2 gemountet und seit dem gehts (ok, er meckert, daß da ext3 IDs drauf sind - wen störts).
Auf einem anderen Rechner das gleiche - dort hab ich allerdings "damals" das CD-Rom abgestöpselt und es gibt, aber jetzt erscheint mir das nur eine andere Lösung des Problems.
Wer kennt ähnliches mit ext3 auf mehreren Platten mit CD-Rom-Laufwerken am gleichen IDE-Bus?
--
$ cd /dos/c/MICROSO~1
$ rm -rf *
|
|
|
|
|
