Categories
System Administration

Getting Ext3/4 journal size

Ext3 is a successor of Ext2 with support for journaling which means it can have a log of all it’s recent changes it made or is going to make to the file system. This allows fsck to get the file system back in a good state when a power failure happens for example. But what is the size of the journal? Reading the manpage for tune2fs it says it needs to be between 1024 and 102400 blocks which means it can start with 1MB on a file system with a 1KB block size and 4M on a file system with 4KB block size.

So let start to see which inode contains the journal and normally this should be inode 8 unless you have a file system that was upgraded from Ext2 to Ext3/4.

$ sudo LANG=C tune2fs -l /dev/sda1 | awk '/Journal inode/ {print $3}'
8

Now that we have the inode responsible for the in file system journal we can retrieve it details by doing a stat() with debugfs for that inode. Debugfs retrieve the details from the inode and on of them is de allocated size on disk.

$ sudo LANG=C debugfs -R "stat <8>" /dev/sda1 | awk '/Size: /{print $6}'|head -1
debugfs 1.42.4 (12-Jun-2012)
4194304

Now let use the same procedure on an other file system:

$ sudo LANG=C tune2fs -l /dev/mapper/data00-srv | awk '/Journal inode/ {print $3}'
8
$ sudo LANG=C debugfs -R "stat <8>" /dev/mapper/data00-srv | awk '/Size: /{print $6}'|head -1
debugfs 1.42.4 (12-Jun-2012)
134217728

There is also an easy way as dumpe2fs provides an interface to a lot of these values directly.

$ sudo LANG=C dumpe2fs /dev/mapper/data00-srv | grep ^Journal
dumpe2fs 1.42.4 (12-Jun-2012)
Journal inode:            8
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke
Journal size:             128M
Journal length:           32768
Journal sequence:         0x0111fd4c
Journal start:            3380

Keep in mind that changing something on a live journal can destroy your file system, so never move the journal location or change it’s size unless it’s a clean unmounted file system.

Categories
Internet, Unix en security

Inodes, inodes, inodes en toen waren ze op

Soms heb je van die dagen dat er ineens een bericht krijgt dat een dienst geen data meer verwerkt. Bij controle lijkt er weinig te vinden te zijn, want er is oa nog voldoende vrije ruimte op het filesysteem is. De applicatie klaagt toch dat hij niet kan schrijven.

Bij verdere controle komt er toch een oude instinker naar boven. Er blijkt een filesysteem geen vrije inodes meer te hebben en er kan dus ook geen expire van data meer worden gedaan door de applicatie. De enige twee opties zijn dus het vrij maken van enkele inodes of extra inodes beschikbaar stellen. Helaas is de eerste optie niet echt een optie als de data belangrijk is of index afhankelijk. De tweede optie van het logische volume en daarna het filesystem vergroten.

Bij het lezen van de manpage voor ext2/3/4 blijft dat je niet kan opgeven of je inodes kan reserveren voor de root-gebruiker zoals bij het aantal beschikbaar vrije blokken. Dit doet me ook verwonderen hoe dit in ZFS is opgelost, maar het wordt wel duidelijk dat filesystemen gebaseerd op inodes hun beste tijd hebben gehad.

Categories
Internet, Unix en security

Ext3 is nog geen ZFS

Helaas is het ext3-filesysteem niet gelijkwaardig als ZFS waarbij fsck niet meer nodig is door oa de copy-on-write strategie. Gelukkig heeft ext3 wel een journal welke kan worden gebruikt om een filesysteem te herstellen als het filesysteem niet netjes wordt afgesloten zoals bij een stroomstoring bijvoorbeeld. Maar helaas is het nog wel nodig om soms een volledige controle uit te voeren om de integriteit te controleren.

Hier komt ook een probleem voor veel gebruikers aangezien de grote van filesystemen groeit en filesystemen van een paar honderd gigabyte tot een terabyte of soms zelfs meer zijn niet meer ongewoon. Je bent dan gewoon veel tijd kwijt aan het wachten totdat een controle is voltooid. Gelukkig is ext3 nu wel lang genoeg op de markt om aan te nemen dat het wel snor zit en hardwarefouten kan ext3 toch niet detecteren en oplossen, iets wat ZFS wel kan trouwens.

Het volgende commande zet dan ook een tijdslimiet van 12 maanden op het filesysteem en de controle zal dan ook maar eens per 12 maanden worden uitgevoerd. Dit ongeacht het aantal keren dat het filesysteem is gebruikt.

$ sudo tune2fs -c 0 -i 12m /dev/mapper/nemo01-home

Het bovenstaande natuurlijk alleen uitvoeren als je weet wat je doet en over goede back-ups beschikt.