Welche Größe hat der interne Log bei JFS2

inline log size

Eine triviale Frage über die wir kürzlich gestolpert sind:

Wie groß ist denn der interne JFS2 Log aktuell?

Die Größe des internen JFS2 Logs muss die folgenden beiden Bedingungen erfüllen:

    1. Der Log kann nicht größer als 10% der Dateisystem-Größe sein.
    2. Die maximale Größe kann 2047 MB nicht überschreiten.

Beim Anlegen eines JFS2 Dateisystems mit internem Log, wenn keine Log-Größe (-a logsize=Value) angegeben wird, werden standardmäßig 0.4% der Dateisystem-Größe verwendet. Der Wert 0.4% ist in der Manual Page zu crfs dokumentiert.

Aber, wie groß ist denn der interne JFS2 Log gerade?

Diese Information liefert das Kommando dumpfs. Es erwartet als Argument entweder den Mount-Punkt eines JFS2 Dateisystems oder die Geräte-Datei des unterliegenden Logical Volumes. Das Kommando listet den Superblock, sowie eine Reihe weiterer Verwaltungs-Informationen auf. Die Ausgabe kann bei größeren Dateisystemen sehr lang sein. Da wir nur an dem JFS2 Log interessiert sind, empfiehlt es sich die Ausgabe durch das Kommando grep zu filtern:

# dumpfs /data | grep -i log
aggregate block size    4096            log2 of aggregate block size    12
LVM I/O Transfer size   512             log2 of LVM transfer  size      9
log2 of block size/transfer size        3
Aggregate attributes    J2_GROUPCOMMIT J2_INLINELOG
log device      0x8000002700000001 log serial number    0x26
Inline Log: 541065216 (132096); 1024
fsck Service Log number of blocks: 50
Extendfs Inline Log Working Space: 541065216 (132096); 1024
#

Der letzte Wert in der Zeile „Inline Log:“ gibt die Größe des internen Logs in Blöcken an. Die Blockgröße des Dateisystems findet man in der Zeile „aggregate block size“. In unserem Falle hat der interne Log eine Größe von 1024 Blöcken, zu jeweils 4096 Bytes. Dies ergibt eine Größe von 4 MB (1024 * 4 KB).

Für den Fall das ein externer Log verwendet wird, sieht die Ausgabe wie folgt aus:

# dumpfs / | grep -i log
aggregate block size    4096            log2 of aggregate block size    12
LVM I/O Transfer size   512             log2 of LVM transfer  size      9
log2 of block size/transfer size        3
log device      0x8000000a00000003 log serial number    0xb
Inline Log: 0 (0); 0
fsck Service Log number of blocks: 50
Extendfs Inline Log Working Space: 0 (0); 0
#

Der interne Log hat die Größe 0 Blöcke.

Allerdings ist dies nicht die einfachste Möglichkeit. Chris Gibson weist auf die Option „-q“ des Kommando lsfs hin, welche für JFS und JFS2 Dateisysteme zusätzliche Informationen anzeigt:

# lsfs -q /filesystem
Name            Nodename   Mount Pt               VFS   Size    Options    Auto Accounting
/dev/fslv01     --         /filesystem            jfs2  1048576 --         no   no
  (lv size: 1048576, fs size: 1048576, block size: 4096, sparse files: yes, inline log: yes, inline log size: 4, EAformat: v1, Quota: no, DMAPI: no, VIX: yes, EFS: no, ISNAPSHOT: no, MAXEXT: 0, MountGuard: no)
#

Die Größe des Inline Logs wird dort direkt in MB angegeben (inline log size: 4).

Die Größe des internen JFS2 Log festzustellen ist also mit dem richtigen Kommando (dumpfs lsfs) kein Problem!

0516-787 extendlv: Maximum allocation for logical volume lv01 is 512

Wenn beim Erweitern eines Logical Volumes oder Dateisystems die folgende Meldung auftritt:

# chfs -a size=+5G /fs01
0516-787 extendlv: Maximum allocation for logical volume fslv01
        is 512.
#

Dann liegt die Ursache an einer Begrenzung des Logical Volumes. Ein Logical Volume ist in der Größe begrenzt durch die maximale Anzahl von LPs (Logical Partitions) die für das Logical Volume allokiert werden können. Die Fehlermeldung sagt auch genau das und gibt sogar den aktuellen Wert für die maximale Anzahl LPs an. Dies ist ein änderbares Attribut des Logical Volumes und kann mit dem Befehl lslv angezeigt werden:

$ lslv fslv01
...MAX LPs:            512                    PP SIZE:        8 megabyte(s)
...$

Geändert werden, kann das Attribut mit dem Kommando chlv:

# chlv -x 768 fslv01
#

Bei der PP (Physical Partition) Größe von hier 8 MB, reichen 768 PPs für genau 6 GB. Man könnte natürlich schon mal die nächste Erweiterung berücksichtigen und den Wert entsprechend höher setzen.

Sollten in der unterliegenden Volume Gruppe genügend PPs frei sein, und auch keine anderen Begrenzungen überschritten werden, dann sollte man das Dateisystem oder Logical Volume jetzt erweitern können:

# chfs -a size=+5G /fs01
Filesystem size changed to 12582912
Inlinelog size changed to 24 MB.
#

AIX: Anwendungen des namefs-Filesystems

Gelegentlich benötigt man ein Verzeichnis (oder ein Filesystem) an einer anderen Stelle im Filesystem oder vielleicht sogar an mehreren verschiedenen Stellen im Filesystem. Anstatt das Problem mit symbolischen Links zu lösen, kann man elegant das namefs-Filesystem zum Einsatz bringen.

In folgenden Beispie wird /data/in an anderer Stelle benötigt:

# ls -l /data/in
total 16
-rw-r--r--    1 root     system          554 May 14 16:10 file1
-rw-r--r--    1 root     system          381 May 14 16:10 file2
# ls -l /other/place
total 0
#

Mounten des Directories an die gewünschte Stelle /other/place:

# mount -v namefs /data/in /other/place
# ls -l /other/place
total 16
-rw-r--r--    1 root     system          554 May 14 16:10 file1
-rw-r--r--    1 root     system          381 May 14 16:10 file2
#

Der Mount mit dem namefs-Filesystem bietet zusätzlich die Möglichkeit Mount-Optionen anzugeben, die dann nur für das Verzeichnis gelten. Man kann damit z.B. ein Verzeichnis auch mit Direct-I/O Mounten, obwohl das ursprüngliche Verzeichnis nicht mit Direct-I/O gemountet wurde:

# mount -v namefs -o dio /data/in /other/place
# mount
  node       mounted        mounted over    vfs       date        options     
-------- ---------------  ---------------  ------ ------------ ---------------
         /dev/hd4         /                jfs2   May 02 11:30 rw,log=/dev/hd8
...
         /data/in         /other/place     namefs May 14 16:14 rw,dio         
#

Bei Zugriffen auf die Dateien unterhalb /other/place wird nun Direct-I/O verwendet, greift man aber über die „Originale“ unter /data/in zu, wird kein Direct-I/O verwendet!

Der Zugriff auf Dateien ist allerdings wie bei NFS auf das unterliegende physikalische Filesystem beschränkt. Dies läßt sich leicht anhand des Filesystems / demonstrieren. Wir mounten / per namefs unter /mnt und schauen uns /mnt/usr und /mnt/var an:

# mount -v namefs / /mnt
# ls -l /mnt/usr /mnt/var
/mnt/usr:
total 0
lrwxrwxrwx    1 root     system           11 Apr 17 07:49 lib -> /../usr/lib

/mnt/var:
total 0
#

Die Verzeichnisse sind leer bzw. enthalten einen symbolischen Link, /usr und /var sehen etwas anders aus!

Dies kann man natürlich auch ausnutzen, z.B. in Fällen bei denen interessante Daten übermountet wurden. Wir haben unterhalb von /home eine Datei abgelegt, bevor /dev/hd1 auf /home gemountet wurde. Über das gerade auf /mnt gemountet root-Filesystem kann man auf diese übermounteten Daten zugreifen:

# ls -l /mnt/home
total 0
-rw-r--r--    1 root     system            0 May 14 17:48 overmounted_file
#

Eine weitere Anwendung besteht darin ein Verzeichnis vor überschreiben zu schützen. Wir demonstrieren dies am Verzeichnis /data mit 2 Test-Dateien:

# ls -l /data
total 16
-rw-r--r--    1 root     system          554 May 14 17:52 file1
-rw-r--r--    1 root     system          381 May 14 17:52 file2
# cp /etc/hosts /data
# ls -l /data
total 24
-rw-r--r--    1 root     system          554 May 14 17:52 file1
-rw-r--r--    1 root     system          381 May 14 17:52 file2
-rw-r--r--    1 root     system         2075 May 14 17:54 hosts
#

Überschreiben oder Ändern von Daten ist aktuell noch möglich, wie das erfolgreiche cp-Kommando zeigt. Jetzt schützen wir die Daten, indem wir einen Mount mit dem namefs-Filesystem und der Option ro (Read-Only) durchführen:

# mount -v namefs -o ro /data /data
# cp /etc/services /data
cp: /data/services: Read-only file system
#

Die Daten können offensichtlich nicht mehr geändert werden. Hier haben wir /data mit einer Read-only Version von sich selbst übermountet!

Mounts mit dem Pseudo-Filesystem namefs können nicht nur auf jfs2-Filesystemen, sondern auch für NFS-Filesysteme oder das procfs-Filesystem durchgeführt werden.

Als Letztes zeigen wir noch das Mounten einer Datei an einer anderen Stelle des Filesystems. Wir wollen die Datei /etc/hosts über den Namen /hosts verfügbar machen. Dazu legen wir zunächst eine leere Datei /hosts an und mounten dann die Datei /etc/hosts über diese leere Datei:

# touch /hosts
# ls -l /hosts
-rw-r--r--    1 root     system            0 May 14 17:59 /hosts
# mount -v namefs /etc/hosts /hosts
# ls -l /hosts
-rw-rw-r--    1 root     system         2075 Apr 26 10:47 /hosts
#

Vor dem Mount ist /hosts 0 Bytes groß, nach dem Mount 2075 Bytes!

Das namefs-Filesystem bietet also einige interessante Möglichkeiten, die bei einige Problemstellungen nützlich sein können.