Categories
Internet, Unix en security

Transitie naar /run

In een vorige posting gaf ik al een hint naar de transitie naar /run en voor ongeveer een week geleden zijn de packages geüpload naar Debian Unstable. Maar wat brengt deze transitie? Eigenlijk het gebruik van tmpfs voor oa /var/run, /var/lock en /tmp, maar ook uiteindelijk /etc/mtab te verhuizen naar /proc/mounts.

Na het upgraden van alle sysvinit-packages en een paar kleine aanpassingen aan /etc/default/rcS zag df er als volgend eruit.

$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg00-root  19G  9.3G  8.2G  54% /
tmpfs                 5.0M     0  5.0M   0% /lib/init/rw
tmpfs                 788M  744K  788M   1% /run
tmpfs                 5.0M     0  5.0M   0% /run/lock
tmpfs                 1.6G  152K  1.6G   1% /tmp
udev                   10M  4.0K   10M   1% /dev
tmpfs                 1.6G  516K  1.6G   1% /run/shm
/dev/sda1             236M   47M  178M  21% /boot
/dev/mapper/vg00-home 854G  707G  104G  88% /home
/dev/sr0              6.6G  6.6G     0 100% /media/cdrom0

Nu worden /var/run en /var/lock ook met een symlink omgeleid naar /run en hiermee komt ook een einde eigenlijk dat packages directories kunnen aanmaken in /var/run bijvoorbeeld of een directory bestaat.

$ ls -ld /var/run /var/lock /tmp
drwxrwxrwt. 11 root root 280 mei 25 01:15 /tmp
lrwxrwxrwx.  1 root root   9 mei 23 22:51 /var/lock -> /run/lock
lrwxrwxrwx.  1 root root   4 mei 23 22:51 /var/run -> /run

Hiermee is eigenlijk de weg vrijgemaakt om de transitie van SysV init-style naar systemd v25 te beginnen, maar eerst is het wachten totdat alle packages Debian Testing bereiken zodat er enige vastigheid is. Met systemd v25 alleen nog in experimental kan dat nog wel even duren, maar aan de andere kant de freeze periode voor Wheezy is voorlopig nog niet gestart.

Categories
Internet, Unix en security

Debian optimaliseren

In een andere posting schreef ik over filesystemen in geheugen. Gelukkig maakt oa Debian vorderingen in hoe dit automatisch te doen, maar ook om packages veilig te maken om ze te gebruiken op systemen met filesystemen in het geheugen. Helaas is dit voorlopig alleen beschikbaar voor de directories /var/lock en /var/run.

De eerste aanpassing is in /etc/default/rcS waar wordt aangegeven welke filesystemen in het geheugen moeten worden aangemaakt. Aanpassingen aan /etc/fstab zijn dan niet meer nodig en weten sommige scripts ook dat ze anders moeten acteren.

RAMRUN=yes
RAMLOCK=yes

Voeg de volgende regels toe aan /etc/default/tmpfs waarmee limieten worden gezet aan de omvang van de filesystemen.

RUN_SIZE=10M
LOCK_SIZE=10M

Na een reboot geeft een df commando de volgende output.

$ df -h | grep ^var
varrun                 10M  136K  9,9M   2% /var/run
varlock                10M     0   10M   0% /var/lock

Het is belangrijk om te beseffen dat dit alles is uitgetest op de aankomende Squeeze-release van Debian. Wees dus voorzichtig met eerdere releases en controleer altijd of het goed werkt.

Categories
Internet, Unix en security

Geheugen filesystem onder Linux

Onder Solaris zijn geheugen gebaseerde filesystemen al jaren gemeengoed en zo zijn bijvoorbeeld /var/run en /tmp de meest bekende filesystemen die in geheugen worden gehouden. Linux heeft ook al flink wat jaren ondersteuning voor geheugen gebaseerde filesystemen, maar lijkt niet echt voorstanders te vinden binnen de gemeenschap. Dit terwijl er voordelen zijn omdat geheugen sneller toegankelijk is dan disk en de prijs van geheugen zorgt ervoor dat je eigenlijk niet meer op geheugen hoeft te beknibbelen.

Het eerste voorbeeld versnelt veel Linux-machines bij onder andere het stoppen en starten van het systeem, maar geeft ook minder disk IO. Veel processen schrijven een PID-file weg in de directory /var/run voor eigen gebruik of door andere applicaties. Dit is zinloze ruimte eigenlijk, want deze files zijn alleen van toepassing voor de machine in de huidige staat en hoeven dus ook geen reboot te overleven.

We voegen de onderstaande regel toe aan /etc/fstab en reboot hierna om alles files in /var/run correct op de nieuwe locatie te krijgen. Maar wat doet deze regel nu echt. Het zorgt ervoor dat er een geheugen gebaseerd filesysteem van maximaal 4MB wordt gemount op /var/run met de correcte permissies en de noexec flag. Deze laatste is niet nodig maar zorgt ervoor dat niemand daar een bestand kan plaatsen en dan kan executen.

/dev/shm   /var/run   tmpfs noexec,size=4m,mode=0755,uid=0,gid=0 0 0

Een andere plek waar veel te winnen is /tmp en zoals FHS aangeeft hoeven bestanden op deze locatie een reboot niet te overleven. Er is alleen wel een uitdaging met /tmp dat de juiste grote wordt gekozen om problemen met ruimte te kort te voorkomen. In dit voorbeeld zijn de beperkingen op wat mag met dit filesysteem wat scherper gezet en behoeft bij oa Debian wat aanpassingen aan APT. Ook is er een limiet gezet van maximaal 256MB, maar deze kan online met een remount worden vergroot en verkleint.

/dev/shm   /tmp   tmpfs noexec,nosuid,nodev,size=256m,mode=7777,uid=0,gid=0 0 0

Wat levert het op? Minder disk IO en iets snellere applicatie, want een gemiddelde disk haalt z’n 20MB per seconde en hedendaags geheugen als minimaal 1800MB per seconde. Dit is dan ook iets wat voor applicaties met veel tijdelijke bestanden zoals bij amavisd-new een grote performance impact kan hebben. Ook levert dit inzichten op om te kijken of Linux zonder disken kan werken of met een minimale disktoegang mogelijk is. Iets wat nu bij Flashdrives al een voordeel heeft om de levensduur te verlengen van een Flashdrive door het aantal writes te beperken.

Het levert ook besparing qua energie en warmte op doordat disken meer in idle-state kunnen verkeren en zometeen als Linux 2.6.25 a 2.6.26 beschikbaar komen ook de SATA-link op een lager vermogen kunnen laten draaien. Dit laatste is nog vrij experimenteel, maar de technologie is er en komt beschikbaar. Ik gebruik de technologie van geheugen gebaseerde filesystem nu al een tijdje en de machines zijn stiller geworden omdat er minder vaak naar disk wordt geschreven.