Büyük dosya sistemlerinde fsck çalıştıran bellek yetersiz

Ben sadece 512 MB RAM ile eski bir Debian linux kutusu (çalışan etch) bakıyorum, ama çok fazla harici depolama bağlı. Bir ext3 dosya sistemi 2,7 TB boyutundadır ve fsck bunu kontrol edemez, çünkü bellek yetersiz, bunun gibi bir hata ile:

   Dizin bloğu dizisi ayrılırken hata oluştu: Bellek ayırma başarısız oldu
   e2fsck: iptal edildi

4 GB takas bölümü ekledim ve hala tamamlanmıyor, ancak bu 32 bit bir çekirdek, bu yüzden daha fazla eklemenin yardımcı olacağını düşünmüyorum.

64 bit çekirdeğe önyükleme yapmanın yanı sıra, fsck'i kontrolünü tamamlamanın başka yolları var mı?

64 bit çekirdek ve büyük miktarlarda RAM, fsck'in güzel ve hızlı bitmesini sağlayacaktır. Alternatif olarak, e2fsck'te artık tüm ara sonuçlarını RAM yerine bir dizinde saklamasını söyleyecek bir seçenek var, bu da son derece yardımcı oluyor. Oluşturmak /etc/e2fsck.confaşağıdaki içeriği ile:

[scratch_files]
directory = /var/cache/e2fsck

(Ve tabii ki, dizinin var olduğundan ve birkaç GB boş alan bulunan bir bölümde olduğundan emin olun). e2fsck SLLOOOOWWWWWWW çalıştıracaktır, ancak en azından tamamlanacaktır.

Tabii ki, bu kök FS ile çalışmaz, ancak takasınız varsa yine de kök FS'yi monte etmeyi geçtiniz.

Ben womble önerilen ne denemek sona erdi; benim gibi daha önce e2fsck'te bu yeni işlevselliği görmediyseniz yararlı olabilecek bazı ayrıntılar.

E2fsck için "scratch_files" yapılandırma seçeneği, 1.40.x sürümünde kullanılabilir hale geldi. (Bizim durumumuzda, bu işlevselliği elde etmek için en son Debian dağıtımına geçmek zorunda kaldık.)

Önerilen "directory = / var / cache / e2fsk" seçeneğinin yanı sıra, çalışma dosyaları depolama alanının nasıl kullanılacağını ayarlamak için başka yapılandırma seçenekleri de vardır. "Dirinfo = false" kullandım, çünkü dosya sistemi çok sayıda dosyaya sahipti, ancak çok fazla sayıda dizin içermiyordu. Durum tersine çevrilirse, "icount" seçeneği uygun olur. Bu seçeneklerin tümü e2fsck.conf için kılavuz sayfasında belgelenmiştir.

BTW, Ted T'so bu başlıkta bu seçenekler hakkında yazdı .

E2fsck'in Ted tarafından tahmin edilenden çok daha yavaş çalıştığını buldum. Çoğu zaman% 99,9 CPU kullanımıyla (son derece yavaş eski bir işlemcide) çalışıyordu, bu da bu veri yapılarının bellek yerine diskte saklanmasının yavaşlamanın ana nedeni olmadığını düşündürmektedir. Dosya sisteminde ne saklandığı hakkında başka bir şey e2fsck'i özellikle yavaşlatmış olabilir. Sonunda şimdilik dosya sistemi kontrolünü bıraktım; dosya sistemi bir kontrol içindi, ancak hatalar yoktu (bildiğim kadarıyla), bu yüzden bir hafta süren kesintiye sahip olabileceğimiz daha uygun bir zamanda kontrol etmeyi ayarlayacağım.