Univention Bugzilla – Bug 14207
UCR sync(1)ed gesamtes Dateisystem bei Änderungen
Last modified: 2009-12-21 08:50:11 CET
Bei jeder Änderung an der UCR wird nicht nur die UCR-Datei "gesynct" sondern der gesamte "buffer cache" des Servers, da sync(1) aufgerufen wird. Dies führt zu großen Performanceeinbußen und sollte durch ein fsync(2) ersetzt werden. dev/trunk/ucs/base/univention-config-registry/python/univention/config_registry.py@230-248 def __save_file(self, filename): try: fp = open(filename, 'w') fp.write('# univention_ base.conf\n\n') fp.write(self.__str__()) fp.close() except IOError, (errno, strerror): # errno 13: Permission denied # # suppress certain errors if not errno in [ 13 ]: raise try: os.system('/bin/sync > /dev/null 2>&1') except: pass
Um Problemen mit ext4 und xfs vorzubeugen, sollten wir beim Schreiben von Config-Dateien folgenden Mechanismus verwenden: 1) neue Datei "base.conf.new" schreiben 2) fsync('base.conf.new') 3) rename base.conf.new base.conf Über 1) und 2) wird sichergestellt, daß die Datei wirklich auf dem Device landet und komplett geschrieben ist. Dabei muss nicht mit sync der ganze BufferCache geschrieben werden. 3) ist eine atomare Operation, d.h. entweder hat man die alte, unangetastete Datei oder man hat die neue Datei unter dem Namen "base.conf"
Zusätzlicher Hinweis dazu: http://www.python.org/doc/2.4/lib/os-fd-ops.html#l2h-1544 fsync( fd) Force write of file with filedescriptor fd to disk. On Unix, this calls the native fsync() function; on Windows, the MS _commit() function. If you're starting with a Python file object f, first do f.flush(), and then do os.fsync(f.fileno()), to ensure that all internal buffers associated with f are written to disk.
(In reply to comment #1) > Um Problemen mit ext4 und xfs vorzubeugen, sollten wir beim Schreiben von > Config-Dateien folgenden Mechanismus verwenden: > 1) neue Datei "base.conf.new" schreiben > 2) fsync('base.conf.new') > 3) rename base.conf.new base.conf 4) fsync('/etc/univention') > > Über 1) und 2) wird sichergestellt, daß die Datei wirklich auf dem Device > landet und komplett geschrieben ist. Dabei muss nicht mit sync der ganze > BufferCache geschrieben werden. > 3) ist eine atomare Operation, d.h. entweder hat man die alte, unangetastete > Datei oder man hat die neue Datei unter dem Namen "base.conf" Durch 4) wird das rename auch auf die Platte geschrieben. (Was in diesem Fall ja gewollt ist, denn UCR-Änderungen sollten schon bestehen bleiben...)
Es wird jetzt beim Speichern eine Datei %s.tmpnew angelegt, mit fsync geflusht, nach %s umbenannt und nochmal mit fsync die Datei geflusht. Changelog-Eintrag ist vorhanden. Paket ist gebaut.
Dadurch können im Thin Client chroot keine UCR-Variablen mehr gesetzt werden.
> Es wird jetzt beim Speichern eine Datei %s.tmpnew angelegt, mit fsync geflusht, > nach %s umbenannt und nochmal mit fsync die Datei geflusht. Da im thinclient-basesystem nur Symlinks in /etc/univention/ liegen, die auf die Ramdisk verweisen, ist ein umbenennen hier nicht möglich. Da durch den ebenfalls übernommenen Bug 15518 (Locking beim Schreiben) reduziert sich jedoch das Problem auf mögliche Inkonsistenzen, wenn direkt in die base.conf geschrieben und während des Schreibvorgangs gelesen wird. Für die zukünftige Lösung wurde Bug 15723 erstellt.
Nach dem Update des Basesystems, waren die base.conf-Dateien keine Links mehr: root@master:/var/lib/univention-client-root/etc/univention# ls -la insgesamt 60 drwxr-xr-x 7 root root 4096 24. Sep 05:52 . drwxr-xr-x 77 root root 12288 24. Sep 05:52 .. -rw-r--r-- 1 root root 102 24. Sep 05:52 base.conf -rw-r--r-- 1 root root 102 24. Sep 05:52 base.conf.bak lrwxrwxrwx 1 root root 40 24. Sep 05:51 base-forced.conf -> /ramdisk/etc/univention/base-forced.conf lrwxrwxrwx 1 root root 44 24. Sep 05:51 base-forced.conf.bak -> /ramdisk/etc/univention/base-forced.conf.bak drwxr-xr-x 4 root root 4096 24. Sep 02:51 base.info lrwxrwxrwx 1 root root 38 24. Sep 05:51 base-ldap.conf -> /ramdisk/etc/univention/base-ldap.conf lrwxrwxrwx 1 root root 42 24. Sep 05:51 base-ldap.conf.bak -> /ramdisk/etc/univention/base-ldap.conf.bak Nachdem ich die folgenden Links angelegt habe, funktionierte UCR im Thin Client chroot fast wieder: root@master:/var/lib/univention-client-root/etc/univention# ln -sf /ramdisk/etc/univention/base.conf base.conf root@master:/var/lib/univention-client-root/etc/univention# ln -sf /ramdisk/etc/univention/base.conf.bak base.conf.bak root@master:/var/lib/univention-client-root/etc/univention# ln -sf /ramdisk/etc/univention/base.conf.lock base.conf.lock root@master:/var/lib/univention-client-root/etc/univention# ln -sf /ramdisk/etc/univention/base.conf.tmpnew base.conf.tmpnew root@master:/var/lib/univention-client-root/etc/univention# ln -sf /ramdisk/etc/univention/base.conf.bak.tmpnew base.conf.bak.tmpnew Es kommt dann eine Exception Read-only file system beim os.rename(tmpnewfn, filename) Zeile 267.
Hier ist beim Merge ein Teil verloren gegangen. Rest wurde gemerged. Paket ist neu gebaut.
(In reply to comment #7) > Nach dem Update des Basesystems, waren die base.conf-Dateien keine Links mehr: Das konnte ich nicht reproduzieren. Bei mir waren dort nur korrekte Symlinks vorhanden: root@s61:/var/lib/univention-client-root/etc/univention# ls -l insgesamt 36 lrwxrwxrwx 1 root root 33 25. Sep 12:44 base.conf -> /ramdisk/etc/univention/base.conf lrwxrwxrwx 1 root root 37 25. Sep 12:44 base.conf.bak -> /ramdisk/etc/univention/base.conf.bak lrwxrwxrwx 1 root root 38 25. Sep 12:44 base.conf.lock -> /ramdisk/etc/univention/base.conf.lock lrwxrwxrwx 1 root root 40 25. Sep 12:44 base-forced.conf -> /ramdisk/etc/univention/base-forced.conf lrwxrwxrwx 1 root root 44 25. Sep 12:44 base-forced.conf.bak -> /ramdisk/etc/univention/base-forced.conf.bak lrwxrwxrwx 1 root root 45 25. Sep 12:44 base-forced.conf.lock -> /ramdisk/etc/univention/base-forced.conf.lock drwxr-xr-x 4 root root 4096 25. Sep 10:00 base.info lrwxrwxrwx 1 root root 38 25. Sep 12:44 base-ldap.conf -> /ramdisk/etc/univention/base-ldap.conf lrwxrwxrwx 1 root root 42 25. Sep 12:44 base-ldap.conf.bak -> /ramdisk/etc/univention/base-ldap.conf.bak lrwxrwxrwx 1 root root 43 25. Sep 12:44 base-ldap.conf.lock -> /ramdisk/etc/univention/base-ldap.conf.lock lrwxrwxrwx 1 root root 42 25. Sep 12:44 base-schedule.conf -> /ramdisk/etc/univention/base-schedule.conf lrwxrwxrwx 1 root root 46 25. Sep 12:44 base-schedule.conf.bak -> /ramdisk/etc/univention/base-schedule.conf.bak lrwxrwxrwx 1 root root 47 25. Sep 12:44 base-schedule.conf.lock -> /ramdisk/etc/univention/base-schedule.conf.lock > Es kommt dann eine Exception Read-only file system beim os.rename(tmpnewfn, > filename) Zeile 267. os.rename wird in dem neuen Paket gar nicht verwendet. Irgendwas ist hier bei deinem Update schiefgelaufen.
Code ist entsprechend angepasst, die Links in der Thin-Client Root sind gesetzt base.conf -> /ramdisk/etc/univention/base.conf base.conf.bak -> /ramdisk/etc/univention/base.conf.bak base.conf.lock -> /ramdisk/etc/univention/base.conf.lock base-forced.conf -> /ramdisk/etc/univention/base-forced.conf base-forced.conf.bak -> /ramdisk/etc/univention/base-forced.conf.bak base-forced.conf.lock -> /ramdisk/etc/univention/base-forced.conf.lock base.info base-ldap.conf -> /ramdisk/etc/univention/base-ldap.conf base-ldap.conf.bak -> /ramdisk/etc/univention/base-ldap.conf.bak base-ldap.conf.lock -> /ramdisk/etc/univention/base-ldap.conf.lock base-schedule.conf -> /ramdisk/etc/univention/base-schedule.conf base-schedule.conf.bak -> /ramdisk/etc/univention/base-schedule.conf.bak base-schedule.conf.lock -> /ramdisk/etc/univention/base-schedule.conf.lock und der changelog.tex Eintrag ist vorhanden.
UCS 2.3 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden: "Clone This Bug".