jfs

Auf einigen (älteren!) Internetseiten stand, dass jfs nicht intressant und noch nicht stabil genug sei (Quelle finde ich nicht mehr, irgend ein Linux Magazin) und deshalb für den Gebrauch nicht intressant -- 2004

Update: Ich verwende nach wie vor für einige Systeme jfs, migriere aber nach ext4, aus folgenden Gründen:

• jfs ist zwar resourcenschonend, aber doch wesentlich langsamer als ext4 beim ersten Zugriff auf Daten
• Der lost+found Ordner quillt ständig über, auch wenn es gar keine Stromausfälle gab
• Fast alle Vorteile von jfs(siehe restlichen Artikel) sind entweder obsolete (utf) oder wird von ext4 auch schon beherrscht.

So oder so, kann in lvm auf jeden Fall empfehlen, da dadurch einiges viel einfacher wird:

• Mehrere Partitionen einfach und flexibel möglich
• Wechsel zwischen Dateisystemen
• Vergrößern/Verkleinern
• "Defragmentieren" durch neuanlegen von Partition
• Upgrade von OS gefahrlos mit "undo" durch snapshots/neues rootfs

Technische Daten

Aufbau

0 kb--
Bootblock
4 kb--
Superblock
Bitmap Datenblöcke
Bitmap I-Nodes
128 kb --
i-Nodes

Datenblöcke


8 MB --
i-Nodes

Datenblöcke

16 MB --
...

Im Superblock sind folgende Daten:

• Dateisystemgröße
• Anzahl der Blöcke im Dateisystem
• Status
• Größe der Allokationsgruppe

I-Nodes

I-Nodes enthalten neben den üblichen Daten auch gleich 8 Referenzen von direkten Datenblöcken. Das kann vorallem bei Verzeichnissen mit wenigen Einträgen ein Geschwindigkeitsvorteil sein, da der I-Node immer geladen werden muss.

In den anderen Fällen wird mit indirekter Adressierung in einem B+ Baum (JFS2) gearbeitet.

Fragmentierung

Dateien wesentlich kleiner als 4kb (bzw. Bruchstücke die von anderen Dateien übrigbleiben) müssen nicht umbedingt einen ganzen 4kb Block belegen. In dem Fall reden wir von Fragmentierung.

Während im AIX defragfs(1) vorhanden ist, gibt es das für Linux leider nicht. Um Daten frisch zu schreiben muss der Ordner kopiert und das Orignial gelöscht werden. Das macht aber nur Sinn (wenn überhaupt) wenn die Auslastung unter 90% ist.

Snapshoting ist auch ein Feature welches nur in AIX vorhanden ist.

Vorteile

1. Geschwindigkeit

   Jfs hat auch Hashes wie andere Dateisysteme. Bei jfs können bis zu 8 Dateien/Verzeichnisse direkt im Metabereich untergebracht werden. Caching funktioniert hervorragend, ein zweites ls startet komplett ohne Verzögerung auch bei *sehr* großen Verzeichnissen.

2. Größen

   Es kann problemlos mit 30000 Dateien in einem Verzeichnis umgehen. Es ist ein 64 Bit Dateisystem - Dateien und Gesamtgrößen sind weit höher als was man physikalisch zusammenschließen könnte.

3. Vergrößern

   Remount vergrößert automatisch den Platz wenn Parition verändert wurde. (Shrink ist nicht möglich)

4. Charsets

   iocharset: Man kann Dateien latin1 codieren, die aber in Wirklichkeit in utf8 auf die Platte landen. Dadurch ist dann ein leichter Wechsel auf utf8 möglich. Update: Jetzt habe ich überall utf8 am laufen, das Wechseln hat problemlos auch ohne convmv funktioniert!

5. Kaum Fragmentierung

   Ich betreibe jfs Dateisysteme schon seit Jahren ohne eine Verlangsamung feststellen zu können. Es gilt aber der Grundsatz, dass man nicht über 90% vollschreiben sollte.
6. Datenblöcke 8 MB -- i-Nodes Datenblöcke 16 MB -- ... Im Superblock sind folgende Daten:
   • Dateisystemgröße
   • Anzahl der Blöcke im Dateisystem
   • Status
   • Größe der Allokationsgruppe

   I-Nodes

   I-Nodes enthalten neben den üblichen Daten auch gleich 8 Referenzen von direkten Datenblöcken. Das kann vorallem bei Verzeichnissen mit wenigen Einträgen ein Geschwindigkeitsvorteil sein, da der I-Node immer geladen werden muss.

   In den anderen Fällen wird mit indirekter Adressierung in einem B+ Baum (JFS2) gearbeitet.

   Fragmentierung

   Dateien wesentlich kleiner als 4kb (bzw. Bruchstücke die von anderen Dateien übrigbleiben) müssen nicht umbedingt einen ganzen 4kb Block belegen. In dem Fall reden wir von Fragmentierung.

   Während im AIX defragfs(1) vorhanden ist, gibt es das für Linux leider nicht. Um Daten frisch zu schreiben muss der Ordner kopiert und das Orignial gelöscht werden. Das macht aber nur Sinn (wenn überhaupt) wenn die Auslastung unter 90% ist.

   Snapshoting ist auch ein Feature welches nur in AIX vorhanden ist.

   Vorteile

   1. Geschwindigkeit

      Jfs hat auch Hashes wie andere Dateisysteme. Bei jfs können bis zu 8 Dateien/Verzeichnisse direkt im Metabereich untergebracht werden. Caching funktioniert hervorragend, ein zweites ls startet komplett ohne Verzögerung auch bei *sehr* großen Verzeichnissen.

   2. Größen

      Es kann problemlos mit 30000 Dateien in einem Verzeichnis umgehen. Es ist ein 64 Bit Dateisystem - Dateien und Gesamtgrößen sind weit höher als was man physikalisch zusammenschließen könnte.

   3. Vergrößern

      Remount vergrößert automatisch den Platz wenn Parition verändert wurde. (Shrink ist nicht möglich)

   4. Charsets

      iocharset: Man kann Dateien latin1 codieren, die aber in Wirklichkeit in utf8 auf die Platte landen. Dadurch ist dann ein leichter Wechsel auf utf8 möglich. Update: Jetzt habe ich überall utf8 am laufen, das Wechseln hat problemlos auch ohne convmv funktioniert!

   5. Kaum Fragmentierung

      Ich betreibe jfs Dateisysteme schon seit Jahren ohne eine Verlangsamung feststellen zu können. Es gilt aber der Grundsatz, dass man nicht über 90% vollschreiben sollte.
   6. 8.2 ext4 as rootfs + jfs as homefs 31.6 26.7 33 52.3 24.2 37 7.0 5.6 ext4 as rootfs + ext4 as homefs 31.1 27.7 25.6 51.1 23.2 26 8.0 4.1 everything ext4+SSD 29.2 1.2 18 19 30 34.93 7.5 2.1

      Info: Die drastische Geschwindigkeitszunahme von 30sec zu 1sec für den kernel laden entstand weil der ursprünglich verwendeter USB Stick sehr langsam war (hdparm: 8MB/sec).

      Namesys

      Die Gesamtzeit ist ziemlich unwichtig, sleep 3 hat 3 Gesamtzeit, verbraucht aber eigentlich keine CPU. Genau so verhält es sich mit jfs. Die Gesamtzeit ist im unteren Durchschnitt, aber die sys/user Zeit ist Spitzenmäßig, ähnlich ext2! Also ein sehr performantes Dateisystem für Desktop-User Zwecke. Diese Daten sind von hier!

      Benchmarks

      power on to grub and grub until kernel loaded should not be influenced by the filesystem test, /boot is mounted on ext2 and was not changed during this test.

      bootchart is a program to be used instead /sbin/init which measures bootup time, here are the graphs:

      

      Filesystem Performance

      fs	bigdir	sys	usr	cp	sys	usr	cp2	sys	usr	cp3	sys	usr	cp4	sys	usr	cp5	sys	usr	rm	sys	usr	rm2	sys	usr	rm3	sys	usr	sync	sys	usr	total	sys	usr	total cpu	fs
      reiserfs	40.03	12.22	0.76	77.75	10.72	0.45	62.9	10.82	0.43	60.26	11.03	0.43	61.33	11.13	0.43	66.08	11.31	0.45	10.86	3.74	0.07	4.62	3.36	0.09	8.22	3.5	0.09	1.78	0.03	0.	393.83	77.86	3.2	81.06	reiserfs
      jfs	47.2	8.9	0.77	109.75	5.5	0.3	110.71	5.49	0.35	114.69	5.6	0.29	117.97	5.65	0.35	125.48	5.82	0.29	38.68

      Bootup Time

      	power on to grub	grub until kernel loaded	init until kdm	kdm to kde menu appears	menu to lock	bootchart	iceweasel start	libreoffice
      jfs as rootfs + jfs as homefs	27.5	24.5	38.0	1:09.3	27.5	47	13.0	8.2
      ext4 as rootfs + jfs as homefs	31.6	26.7	33	52.3	24.2	37	7.0	5.6
      ext4 as rootfs + ext4 as homefs	31.1	27.7	25.6	51.1	23.2	26	8.0	4.1
      everything ext4+SSD	29.2	1.2	18	19	30	32.93	7.5	2.1

      Info: Die drastische Geschwindigkeitszunahme von 30sec zu 1sec für den kernel laden entstand weil der ursprünglich verwendeter USB Stick sehr langsam war (hdparm: 8MB/sec).

      Die Zeiten vom alten bootchart schwanken extrem, am besten die Grafiken selber anschauen.

      jfs

      Disclaimer 2013: Diese Infos sind bereits alt. Wie Benchmarks oben zeigen, ist jetzt ext4 vorzuziehen.

      Auf einigen (älteren!) Internetseiten stand, dass jfs nicht intressant und noch nicht stabil genug sei (Quelle finde ich nicht mehr, irgend ein Linux Magazin) und deshalb für den Gebrauch nicht intressant -- 2004

      Update: Ich verwende nach wie vor für einige Systeme jfs, migriere aber nach ext4, aus folgenden Gründen:

      • jfs ist zwar resourcenschonend, aber doch wesentlich langsamer als ext4 beim ersten Zugriff auf Daten
      • Der lost+found Ordner quillt ständig über, auch wenn es gar keine Stromausfälle gab
      • Fast alle Vorteile von jfs(siehe restlichen Artikel) sind entweder obsolete (utf) oder wird von ext4 auch schon beherrscht.

      So oder so, kann in lvm auf jeden Fall empfehlen, da dadurch einiges viel einfacher wird:

      • Mehrere Partitionen einfach und flexibel möglich
      • Wechsel zwischen Dateisystemen
      • Vergrößern/Verkleinern
      • "Defragmentieren" durch neuanlegen von Partition
      • Upgrade von OS gefahrlos mit "undo" durch snapshots/neues rootfs

      Technische Daten

      Aufbau

      0 kb--
      Bootblock
      4 kb--
      Superblock
      Bitmap Datenblöcke
      Bitmap I-Nodes
      128 kb --
      i-Nodes
      
      Datenblöcke
      
      
      8 MB --
      i-Nodes
      
      Datenblöcke
      
      16 MB --
      ...
      

      Im Superblock sind folgende Daten:
      • Dateisystemgröße
      • Anzahl der Blöcke im Dateisystem
      • Status
      • Größe der Allokationsgruppe

      I-Nodes

      I-Nodes enthalten neben den üblichen Daten auch gleich 8 Referenzen von direkten Datenblöcken. Das kann vorallem bei Verzeichnissen mit wenigen Einträgen ein Geschwindigkeitsvorteil sein, da der I-Node immer geladen werden muss.

      In den anderen Fällen wird mit indirekter Adressierung in einem B+ Baum (JFS2) gearbeitet.

      Fragmentierung

      Dateien wesentlich kleiner als 4kb (bzw. Bruchstücke die von anderen Dateien übrigbleiben) müssen nicht 0.05 15.31 0.71 0.05 0.24 0. 0. 296.61 36.46 2.52 38.98 ext2

      TOP Contact me