Bugün, günün neredeyse tamamı pisi’deki garip bir hata ile uğraşmakla geçti. Takip edenler bilirler. Bir süredir, pisi dosyalarında zip’in “deflated” sıkıştırma algoritmasına göre çok daha iyi sıkıştırma oranlarına sahip olan “lzma” sıkıştırma algoritmasına geçmeye çalışıyoruz. Bazı paketlerimizde %50′ye varan kazançlar elde edebildik. Ortalama kazanç ise %15-%25 civarında oluyor. Pardus-1-test ikili paket depomuzda yer alan paketler, bu çalışmanın ilk ürünleri idi. İlerde standart dışı, ucube bir paket formatına sahip olmak istemediğimizden, işleri olabildiğince düzgün yapmaya çalıştık ve gerek lzma tarafında, gerekse pkware (zip arşivi) tarafında ilgili kişiler ile yazışarak, birlikte çalışmaya gayret ettik.

Fakat, başlarda olumlu giden yazışmaların zamanla bizi yavaşlattığını ve geciktirdiğini gördük. Uzun zaman da pkware’dan cevap alamayınca, biz de çare olarak, yine olabildiğince standart araçlar kullanarak, farklı bir paket formatı geliştirmeye karar verdik. Bu formata göre, pisi - zip arşivi - içerisinde daha önce /install dizini altında bulunan kurulum dosyalarını, lzma utils araçlarını kullanarak, yine pisi içerisinde install.tar.lzma şeklinde saklamaya başladık. Sağolsun, Onur da süper yaması ile mc’nin tar.lzma’yı tanımasını sağladı.

Ancak sorunlar bir türlü bitmek bilmedi. Tam herşey yolunda gidiyor derken, bahsettiğim garip pisi hatası ile karşılaştık. Nasıl oluyordu da, zlib paketini kurmaya çalışırken, önce shell, sonra kicker, ardından da tüm kde ve X çökebiliyordu. İşin ilginç yanı, lzma öncesi paket formatımızla oluşturduğumuz paketlerde böyle bir sorunla karşılaşmıyorduk. Sonuçta yapılan şey aynıydı, kurulum dosyaları, “/” altına açılıyordu.

Bir süre beraberce çekirdek’ten tutun da, aklımıza neresi geldiyse fikir yürüttük. Daha sonra koda bakmaya başladık. Sorunu lzma utils’in tetikleyebileceğini düşünürek bir süre üzerine gittik. Daha sonra problemi daraltarak, pisi paketi içinde lzma ile sıkıştırılmış olan install.tar dosyasına kadar geldik. Yazdığımız basit bir python script’i, install.tar’ı “/” dizinine açmamızla tüm sistemi çökertiyordu. Buradan da hatayı tarfile.py’ye kadar indirebildik. İşte burada Barış‘ın müthiş asod modülleri devreye girdi. Kullanımı hakkında bir fikir sahibi değilim ama hakikaten harika bi şeymiş bu asod, canım. (sanırım bu kadar reklam yeter, reklam parasını da sonra tahsis ederim :) ) Barış, asod ile tarfile içinde copyfileobj’ye kadar sorunu indirgedi. Burada da çeşitli fikirler yürüttük ve denemeler yaptık. Tam shutils’i suçlamaya başlarken, install.tar içini tek bir dosyaya kadar indirip, yine açıldığında sistemi çökertir hale geldiğini de görünce; eee madem bu kadar geldik, şu tar içinde son kalan zlib.so.1.2.3 isimli dosyayı elle kopyalayalım bare dedik veeee sistem yine gitti. İlginç yanı mv ettiğimizde sistem çalışmaya devam ediyor, dosya’yı cp yaptığımızda sistem gidiyordu.

Akşam oldu ve servislere doğru ilerlerken İsmail ile konuşmaya başladık. Madem bu shared library olan zlib, mmap ediliyor, eee kardeşim, biz bu dosya’nın üzerine yazıyoruz işte sorun bu olmalı derken, Gürer san, “o zaman dosyaları silelim ve sonra da yeniden yazalım, böylece farklı inode kullanmaya başlarız” diyerek son noktayı koydu. Gürer san, biz tüm gün yoralım yoralım, sen de böyle koyarsın son noktayı tabi.. :)

Evde, bu son konuşmalar üzerine biraz araştırma yapınca, hatanın hakikaten bu olduğu ortaya çıktı. Eski paket formatında zipfile.py, dosyaları extract ederken farklı bir inode ile yazıyordu, tar ise extract içerisinde copyfileobj metodunu kullandığından aynı inode üzerine shared library’yi yazıyordu. O anda shared library’yi map eden, birbiriyle alakasız diğer processler de, aynı inode’a bağlı fakat içeriği değişen dosya ile teker teker seg. fault alıp, kapanıyordu. cp ve mv da aynı sebepten farklı davranıyordu. cp ile inode değişmiyor, mv ile inode değişiyordu.

Tahmin ediyorum ki, 1.1 yolunda karşımıza çıkan en önemli ve sıkıcı problemi de ekipçe aşmış olduk. O zaman ne demek kalıyor… Aşkla geliyoruz… ;)