Archiwa tagu: firebird

Problemów z Reiserfs ciąg dalszy (not directory or indirect item)

Zawsze byłem zadowolony z tego systemu plików, szybki, nie zauważyłem aby robił mi jakieś świństwa po gwałtownym padzie zasilania. Po prostu sprawdza się na domowym komputerku. Za to przysparza problemów tam gdzie pracuje Firebird 1.5 .  Ma dziwną tendencję do psucia się na partycji /tmp , wrzucając do dmesga następujące komunikaty:

ReiserFS: md2: warning: vs-8115: get_num_ver: not directory or indirect item

Konsekwencje tego są bardzo problematyczne i nieciekawe. Z bazy firebirdowej zaczęły znikać rekordy, a może wyrywkowo nie pojawiały się nowe. Trudno powiedzieć, najważniejsze, że nie było tych danych, które powinny tam być. Jest to kolejny powód dla którego zaczynam odchodzić od tego systemu plików. Moim „idolem” jest na obecną chwilę XFS , niestety nie zawsze mogę go zastosować (nie wszędzie jest UPS).

Uzupełnienie: problem pojawiał mi się na różnych wersjach kerneli, poczynając od aruoxowego 2.6.9-coś tam , poprzez gentoo-sources 2.6.16 , 2.6.18, 2.6.23 . Na innych wersjach jądra nie miałem okazji sprawdzać.

Firebird i Reiserfs

Głównymi bohaterami są Firebird 1.5 oraz system plików reiserfs 3.6 .

Baza danych jest pojedynczym (jak to zwykle przy firebirdzie bywa ;) ) plikiem o wielkości od 1 GB do ~5 GB. Podaje taki przedział ponieważ obserwacji dokonywałem na wielu serwerach dla baz o różnej wielkości. Partycja jest zwykle o wielkości ~15-20 GB czyli jest znacznie większa od wielkości pliku.

Sposób pracy na bazie jest klasyczny, czyli dane są dokładane i to w dosyć sporej ilości.

W efekcie już po kilku tygodniach takiej pracy, plik bazodanowej jest bardzo mocno sfragmentowany. Filefrag zgłasza od kilkudziesięciu do nawet 200-300 tysięcy „extentsów”.

W ramach testów przeszedłem na XFS, efekt? Po kilku tygodniach pracy fragmentacja dla pliku ~2GB wynosi: 3 extents. Różnica jest olbrzymia.

Planuję obserwować jak będzie to zachowywać się na EXT3 w ramach alternatywy dla XFSa. I należałoby dać chyba jeszcze szansę reiserowi i zamontować go z opcją „notail”, być może to będzie miało pozytywny wpływ.

Epilog:

Po 3 tygodniach obserwacji, baza na XFS nadal jest w 3 częściach.

Baza umieszczona na Reiserfs zamontowanego z opcją notail, po kilku dniach zwiększyła ilość swoich kawałków z ponad dwóch tysięcy do ponad czterech tysięcy.