Ext4: Journal file too short?

Impressum | Werbung

Geizhals » Forum » Linux-Support »

Ext4: Journal file too short? (16 Beiträge, 270 Mal gelesen)

Top-100 | Fresh-100

Du bist nicht angemeldet. [ Login/Registrieren ]

Hi !

Wieder mal beim experimentieren bei ext4 - diesmal mit internem Log.

Ich lege ein Dateisystem wie folgt an:

root@i5:/usr/local/BackupPC# mkfs.ext4 -b 4096 -E stride=64 -E stripe-width=320 -J size=40000 -O dir_index,extent,large_file,resize_inode,sparse_super,uninit_bg /dev/sata/backuppc
mke2fs 1.41.12 (17-May-2010)
Dateisystem-Label=
OS-Typ: Linux
Blockgröße=4096 (log=2)
Fragmentgröße=4096 (log=2)
Stride=64 Blöcke, Stripebreite=320 Blöcke
72089600 Inodes, 288358400 Blöcke
14417920 Blöcke (5.00%) reserviert für den Superuser
Erster Datenblock=0
Maximale Dateisystem-Blöcke=4294967296
8800 Blockgruppen
32768 Blöcke pro Gruppe, 32768 Fragmente pro Gruppe
8192 Inodes pro Gruppe
Superblock-Sicherungskopien gespeichert in den Blöcken: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
	102400000, 214990848
Schreibe Inode-Tabellen: erledigt                        
Erstelle Journal (10240000 Blöcke): erledigt
Schreibe Superblöcke und Dateisystem-Accountinginformationen: erledigt

Das Dateisystem wird automatisch nach jeweils 38 Einhäng-Vorgängen bzw.
alle 180 Tage überprüft, je nachdem, was zuerst eintritt. Dies kann durch
tune2fs -c oder -i geändert werden.

Wenn ich es mounte, erhalte ich:

# mount /dev/sata/backuppc  daten/
mount: wrong fs type, bad option, bad superblock on /dev/mapper/sata-backuppc,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

# dmesg|tail
...
[547569.681383] JBD2: journal file too short
[547569.681391] EXT4-fs (dm-53): error loading journal

Was habe ich jetzt wieder falsch gemacht?

Wenn ich es korrekt berechnet habe, darf dein Journal bei 4k Blöcken nicht größer sein als 419.430.400 bytes, du gibst aber 40 GB an.

-J journal-options
      Create  the ext3 journal using options specified on the command-
      line.  Journal options are comma separated,  and  may  take  an
      argument using  the  equals ('=')  sign.  The following journal
      options are supported:

   size=journal-size
  Create an internal journal (i.e., stored inside  the
  filesystem)  of  size  journal-size  megabytes.  The
  size of the journal must be at least 1024 filesystem
  blocks  (i.e.,  1MB if using 1k blocks, 4MB if using
  4k blocks, etc.)  and may be no  more  than  102,400
  filesystem blocks.

Dürfte eine Frage sein, wie alt die Tools sind...

Ich habe auf dem Rechner damals folgendes probiert:

# mkfs.ext4 -J test.bin

Ungültige Journal-Optionen wurden angegeben.

Journal-Optionen werden durch Kommatas getrennt. Manche erwarten ein
Argument, welches mit Gleichheitszeichen („=“) zugewiesen wird.

Gültige Journal-Optionen sind:
size=
device=

Die Grösse des Journals muss zwischen 1024 und 10240000 Dateisystem-Blöcken
liegen.

Man beachte, dass um den Faktor 100 mehr FS-Blöcke für das Journal erlaubt sind.
Von da kam ich auf meine 40GB Journal-Size - und dementsprechend habe ich angelegt.

Den Rechner habe ich derzeit nicht zur Verfügung - und habe es inzwischen auf einem anderen probiert. Auf dem anderen stand in der manpage dasselbe wie in der von dir zitierten - aber das mkfs.ext4 meldete das gleiche wie bei mir @home (WTF).

Jetzt noch auf einem dritten Rechner nachgesehen (Debian wheezy) - da meldet sowohl die manpage als auch die mkfs-Gschicht die 10240000 möglichen FS-Blöcke

Scheinbar gab es da also einen Wechsel.
Verblüffend ist für mich nur, dass der erste Rechner einen aktuellen Kernel hat (3.4.4) und das mkfs.ext4 nicht meckerte. Daher sollte es IMHO klappen...

Sodale, gerade wieder ausprobiert:

mkfs.ext4 -b 4096 -E stride=64 -E stripe-width=320 -J size=2048 -O dir_index,extent,large_file,resize_inode,sparse_super,uninit_bg /dev/sata/backuppc

funktioniert fein. Verblüffend ist, dass "size=2048" klappt. Dies dürfte nicht sein, wenn die "102,400" Block-Grenze greifen würde...

Ich habe auch einen Boundary-check für die gemacht und "size=39999" probiert - klappt wieder nicht.

Scheinbar passen die Tools, Kernel und manpages nicht zusammen. Oarg eigentlich.

Jedenfalls Danke für deine Hilfe und fürs manpage-schauen!

23.07.2012, 18:53 Uhr - Editiert von kombipaket, alte Version: hier

Kein Ding! Lustig, dass hier die Komponenten nicht stimmig sind, und die Fehlermeldung purer Schwachsinn ist.

In der Anfangszeit (wohlgemerkt aber nachdem ext4 nicht mehr dev war) habe ich mir mein FS geschossen nach einem manuellen Kernelupdate von 2.6.xx auf xx+1, da habe ich auch nicht schlecht geschaut... naja.

Aber mal ne andere Frage, ich bin ja nicht der Experte aber was würde es dir bringen das Journal zu vergrößern, bzw. von den default-settings abzuweichen?

Größeres Journal bringt oft massiv höhere Performance - zumindest bei XFS.
Die Größe, die ich wählte, ist wohl eh weit zu hoch (auch die 2GB) - nur damit sie halt nicht limitierend wirkt.

Bei ext dürfte es auch so sein:
http://www.linux-mag.com/id/7666/

sollte das teil von sich aus nicht wissen was am günstigsten ist?

Argl.... Woher soll ein FS vorher wissen, wie es eingesetzt wird? Wenn viel IO - ist ein großes Journal besser. Wenn kein schreibender Zugriff - brauchst gar kein Journal

.

Selbst wenn es wüsste, wieviel IO stattfinden wird - woher soll es wissen, ob Du lieber mehr Platz oder mehr Performance hast???

ehm was gibts grossartig an wenn du ein NTFS formatierst? max. vielleicht noch die clustergrösse und das war es.

was gibst bei einem mac grossartig an, wenn du eine partition mit deren filesystem formatierst?

insofern sollte ein einfaches mk.ext4 /dev/... irgendwas reichen und was brauchbares liefern.

Bei NTFS kannst parametrisieren:
- Label

- compression
- cluster-size
- sector-size
- partition-start-sector
- heads
- sectors per track
-mft-zone-multiplier (um den Prozentanteil der MFT festzulegen)
- indexing

BTW, ein Filesystem wo man wenig einstellen kann, ist eher ein schwaches Filesystem.

Beispiele:

- NTFS kennt keine Allocation Groups. Klarerweise gibt es dann auch nichts dazu einzustellen. Ohne Allocation Groups muss es dadurch bei massiv parallelen Zugriffen langsamer sein. Mit ist lieber ich kann da was einstellen als dass die Option fehlt.

- NTFS kennt keine realtime-Volumes, man kann also auch da nichts einstellen. Ist das nun gut oder schlecht?

- NTFS kann zwar journalling - man kann aber dazu nichts einstellen. Ist das gut oder schlecht, wenn man sein FS nicht tunen kann?

- NTFS kennt kein externes Journal. XFS und EXT[34] bieten es als Option an. Ist es gut, wenn man auf ein externes Journal verzichten muss?

....

Natürlich kann man ein FS "einfach so" anlegen, ohne Parameter zu verwenden. Das wäre (um wieder mal einen sinnlosen Auto-Vergleich zu machen) wie ein Auto, das keine Gangschaltung hat sondern immer im "dritten" Gang fährt, weil man damit in der Stadt gut durchkommt. Ich persönlich bevorzuge ein Getriebe, wo man sich überlegen kann, wann man welchen Gang benutzt

-

EDIT:
Ach ja, das MacOS HFS+ lässt sich auch brav parametrisieren: siehe http://manpages.ubuntu.com/manpages/natty/man8/mkfs.hfsplus.8.html

25.07.2012, 06:52 Uhr - Editiert von kombipaket, alte Version: hier

Ah ich seh schon. Lustig auch der letzte Kommentar der auch auf das 102400 Block Limit abzielt

Lustig auch der letzte Kommentar der auch auf das 102400 Block Limit abzielt

Ja, dachte ich mir auch

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung