180 gün sonra fsck veya fsck değil

Varsayılan olarak 180 gün veya bir takım bağlamalardan sonra, çoğu Linux dosya sistemi bir dosya sistemi denetimini (fsck) zorlar. Elbette bu, ext2 veya ext3'teki tune2fs -c 0 -i 0 kullanılarak kapatılabilir.

Küçük dosya sistemlerinde, bu kontrol yalnızca bir rahatsızlıktır. Ancak, daha büyük dosya sistemleri göz önüne alındığında, bu denetimin tamamlanması saatler sürebilir. Kullanıcılarınız üretkenlikleri için bu dosya sistemine güvendiklerinde, ev dizinlerini NFS üzerinden sunduğunu varsayalım, zamanlanmış dosya sistemi kontrolünü devre dışı bırakır mısınız?

Bu soruyu soruyorum çünkü şu anda 2:15 am ve tamamlamak için çok uzun bir fsck bekliyoruz (ext3)!

180 günlük varsayılan fsck süresi, ext3'ün çevrimiçi tutarlılık denetimini desteklemediği tasarım hatası için bir çözümdür. Asıl çözüm, bunu destekleyen bir dosya sistemi bulmaktır. Olgun bir dosya sisteminin olup olmadığını bilmiyorum. Bu gerçek bir trajedi. Belki btrfs bizi bir gün kurtaracak.

Standart bakımın bir parçası olarak tam bir fsck ile planlı yeniden başlatmalar yaparak fsck'den sürpriz çok saatlik kesinti konusuna cevap verdim. Bu, üretim saatleri içinde küçük yolsuzluklardan kaçmak ve gerçek bir kesintiye dönüşmekten daha iyidir.

Sorunun büyük bir kısmı ext3'ün makul olmayan derecede yavaş bir fsck'e sahip olmasıdır. Xfs çok daha hızlı bir fsck olmasına rağmen, büyük dosya sistemlerinde varsayılan olarak xfs'yi teşvik etmek için dağıtımlar için çok fazla bellek kullanır. Yine de, çoğu sistemde bu bir sorun değildir. Xfs'ye geçmek en azından makul derecede hızlı bir fsck'e izin verir. Bu, normal bakımın bir parçası olarak fsck'in programlanmasını kolaylaştırabilir.

RedHat çalıştırıyorsanız ve xfs kullanmayı düşünüyorsanız, xfs kullanımını ne kadar güçlü bir şekilde caydırdıklarına ve çalıştırdığınız çekirdeğe xfs kullanan çok az kişinin olması gerçeğine dikkat etmelisiniz.

Anladığım kadarıyla ext4 projesinin en azından fsck performansını iyileştirmek gibi bir hedefi var.

Bu, üretim sunucularının tek başına çalışmaması ve her zaman bir sıcak / soğuk yedeklemesine sahip olması veya iki düğüm kümesinde yer almasının başka bir nedeni olduğunu söyleyebilirim. Bu sanallaştırma günlerinde, kolayca fiziksel bir ana sunucunuza ve her X günde bir yapılan fizikselin bir kopyası olan ve devralmaya hazır bir sanal sunucunuz olabilir.

Diğer o zaman bu kadar yararlı olmayan cevap, verilerinizin önemini dengelemeniz gerektiğini söyleyebilirim ... Bu sadece bir küme düğümü ise, atlayın. Bu bir müşterinin yedeklenmemiş web sunucusuysa, bir dahaki sefere önceden plan yapmak isteyebilirsiniz :-)

Bağımlı .. Örneğin, QMail yığını çalıştıran rutin bakım için bir sunucumuz vardı. QMail zaman geçtikçe çok sayıda dosya oluşturur ve öldürür ve çok yoğun bir posta sunucusuydu. Fsck yaklaşık 36 saat sürdü. Anlaşmadan bir çok helluva performansı kurtardık gibi değil, ama sonuçta dosya sisteminin daha sağlıklı olduğunu iddia edebileceğinizi düşünüyorum. Gerçi ortaya çıkan kaosa gerçekten değer miydi? Değil. At. Herşey.

XFS ilginç. Her zaman tutarlı bir FS'dir. Fsck'e ihtiyacı yok. Fsck nedeniyle arızaya neden olmaz.

Ama başka bir sorunu daha var. HDD bozuk bloklarıyla uğraşmayı destekleyen bir RAID denetleyicisine ihtiyacınız var.

İşletim sistemi bozuk bloklar hakkında bilgi sahibi olmaya başladığında ve HDD donanım bozuk blokları listesi dolduğunda XFS kötü blokları kara listeye alma özelliğine sahip değildir.

ext2 / 3/4, yağ, ntfs, vb (çevrimdışı test) bozuk blokları kara listeye alabilir ancak XFS'yi listeleyemez.

Bu nedenle, kurumsal olmayan yüklemeler için XFS muhtemelen uygun değildir. İçeriğin zaman içinde fazla değişiklik göstermeyen çok sayıda küçük dosya olduğu yedekleme bölümleri için linux yazılımı raid1 ile XFS kullanıyorum.