reiserfs->ext3 kopiert: kernel: JBD: barrier-based sync failed on sda8 - disabling barriers
Habe zwei reiserfs-Partitionen (root (sda1) und var (sda8)) per rsync auf eine andere Festplatte kopiert. (root natürlich nicht vom laufenden System, sondern mit REttungssystem von DVD). Auf dem neuen System SATA-FEstplatte habe ich seitdem immer mal wieder die Meldung: kernel: JBD: barrier-based sync failed on sda8 - disabling barriers und kernel: JBD: barrier-based sync failed on sda1 - disabling barriers WARUM? Was erinnert ext3 noch an reiserfs bzw was stört ext3 an der Vergangenheit der Daten auf reiserfs-Partition? Warum mich das brennend interessiert, siehe thread "9.2, 2.6.8-24.19: kernel: nfsd: non-standard errno: -16", von vor einer halben Stunde in dieser Liste, dort beschreibe ich bei einem Produktivserver (Büro, 10 Arbeitsplätze) ständig Einfrierungen (deadlocks). Vielleicht hängt diese MEldung ja damit zusammen. danke schonmal Ekkard
Hallo, Am Wed, 18 Jan 2006, Ekkard Gerlach schrieb:
Habe zwei reiserfs-Partitionen (root (sda1) und var (sda8)) per rsync auf eine andere Festplatte kopiert. (root natürlich nicht vom laufenden System, sondern mit REttungssystem von DVD). Auf dem neuen System SATA-FEstplatte habe ich seitdem immer mal wieder die Meldung:
kernel: JBD: barrier-based sync failed on sda8 - disabling barriers und kernel: JBD: barrier-based sync failed on sda1 - disabling barriers
WARUM? Was erinnert ext3 noch an reiserfs bzw was stört ext3 an der Vergangenheit der Daten auf reiserfs-Partition?
==== Documentation/filesystems/ext3.txt des Kernels ==== Journaling Block Device layer ----------------------------- The Journaling Block Device layer (JBD) isn't ext3 specific. It was design to add journaling capabilities on a block device. The ext3 filesystem code will inform the JBD of modifications it is performing (Call a transaction). the journal support the transactions start and stop, and in case of crash, the journal can replayed the transactions to put the partition on a consistent state fastly. ==== -dnh -- Das Ulkige an Linux: Man will sich nur eben ein Mailprogramm einrichten, aber danach kann man dann wahrscheinlich im Heizungskeller gleich sein eigenes GMX aufmachen. -- Stephan Maus
* David Haller schrieb:
WARUM? Was erinnert ext3 noch an reiserfs bzw was stört ext3 an der Vergangenheit der Daten auf reiserfs-Partition?
==== Documentation/filesystems/ext3.txt des Kernels ==== Journaling Block Device layer ----------------------------- The Journaling Block Device layer (JBD) isn't ext3 specific. It was design to add journaling capabilities on a block device. The ext3 filesystem code will inform the JBD of modifications it is performing (Call a transaction). the journal support the transactions start and stop, and in case of crash, the journal can replayed the transactions to put the partition on a consistent state fastly.
ok, ich denke ich habe verstanden was JBD sein soll. Warum aber sind 4 andere Partitionen, die vorher bereits ext3 waren und wiederum auf eine ext3 kopiert wurden OHNE DIESE FEHLERMELDUNG? ========================= (sorry, das hatte ich im OP vergessen zu erwähnen) Ein tune2fs -l /dev/sda8 zeigt übrigens das gleiche wie bei den "intakten" ext3-Partition, bei denen also JBD funktioniert. Woran könnte es liegen? danke schon mal Ekkard
Hallo, Am Wed, 18 Jan 2006, Ekkard Gerlach schrieb:
* David Haller schrieb:
WARUM? Was erinnert ext3 noch an reiserfs bzw was stört ext3 an der Vergangenheit der Daten auf reiserfs-Partition?
==== Documentation/filesystems/ext3.txt des Kernels ==== Journaling Block Device layer [..] ok, ich denke ich habe verstanden was JBD sein soll. Warum aber sind 4 andere Partitionen, die vorher bereits ext3 waren und wiederum auf eine ext3 kopiert wurden OHNE DIESE FEHLERMELDUNG? =========================
(sorry, das hatte ich im OP vergessen zu erwähnen)
Weiss ich auch nicht. Such mal im Archiv der Liste nach 'barrier' bzw. der genauen Fehlermeldung die du bekommst (ggfs. auch ausserhalb des Listenarchivs nach der Fehlermeldung). Da war IIRC was mit patches usw. Ich verwende halt schon Jahre nur vanilla 2.4er Kernel, da weiss ich bzgl. dieser "barrier"-patches und Kernel-2.6 nicht genug. -dnh -- blubb || { echo "Autsch" >&2; exit 1; } [ich, hier, über ein misslungenes Script]
Ekkard Gerlach:
kernel: JBD: barrier-based sync failed on sda8 - disabling barriers kernel: JBD: barrier-based sync failed on sda1 - disabling barriers
WARUM? Was erinnert ext3 noch an reiserfs bzw was stört ext3 an der Vergangenheit der Daten auf reiserfs-Partition?
Das hat damit nichts zu tun. Wie David ja schon schrieb, ist JBD Teil von ext3. Barriers sind eine Methode, mit der (einige) journalführende Dateisysteme sicherstellen, dass das Journal definitiv auf die Platte geschrieben wird und nicht z.B. im Cache der Platte bleibt. Wenn dies mit einer gegebenen (IDE) Festplatte nicht funktioniert, meldet das Dateisystem dies und verwendet für diese Platte keine barriers mehr. Philipp
* Philipp Thomas schrieb:
Ekkard Gerlach:
kernel: JBD: barrier-based sync failed on sda8 - disabling barriers kernel: JBD: barrier-based sync failed on sda1 - disabling barriers
WARUM? Was erinnert ext3 noch an reiserfs bzw was stört ext3 an der Vergangenheit der Daten auf reiserfs-Partition?
Das hat damit nichts zu tun. Wie David ja schon schrieb, ist JBD Teil von ext3. Barriers sind eine Methode, mit der (einige) journalführende Dateisysteme sicherstellen, dass das Journal definitiv auf die Platte geschrieben wird und nicht z.B. im Cache der Platte bleibt. Wenn dies mit einer gegebenen (IDE) Festplatte nicht funktioniert, meldet das Dateisystem dies und verwendet für diese Platte keine barriers mehr.
o.k. Aber warum funktioniert es bei sda2, sda3, sda6 (sda5 ist swap), sda7, sda9, sda10? - Diese Partitionen waren auf dem ursprünglichen System (3ware, Seagate SATA 250GB, Spiegelung) auch schon ext3. Nur eben sda1 und sda8 nicht (sda1 war /, sda8 war /var), diese waren reiserfs. Nochmal: warum funktioniert barrier nur bei Parititionen nicht, die von einer reiserfs-Partition ge'sync't wurden? Am Rand bemerkt: verwende niemals 3ware-SATA-Controller mit reiserfs - mir hat es bei zwei Kunden je auf einen Schlag ALLE reiserfs-Partitionen auf BEIDEN Festplatten vollständig zerschossen, ALLE ext3 waren immer in Ordnung (einmal Suse 8.2, einmal Suse 9.2). In beiden Fällen war je eine Festplatte tatsächlich defekt. Ich "durfte" in einem Fall auf meine Kosten alles neu aufsetzen, der andere Fall lief glimpflich ab, weil nur relativ reduntante Daten auf reiserfs lagen. Ich poste dazu nochmal in diese Liste. Es stehen 3 Stück Raid Controller von 3ware zum Verkauf ... es sind 3 Jahre Herstellergarantie, wer will die [...]? Wenn hier keiner dann ab zu ebay ... Ekkard
participants (4)
-
David Haller -
Ekkard Gerlach -
Philipp Thomas -
Thomas Hertweck