Fsck 30 TB'lık bir hacmi ne kadar süre alabilir?

Kasım ayı ortasında, bir hosting şirketinden kiraladığım bir VPS yanıt vermeyi durdurdu. Desteğe başvurduğumda, veri merkezindeki bir elektrik kesintisinin zorla yeniden başlatmaya ve fsck'e neden olduğunu açıkladılar. Sonunda, neden bu kadar uzun sürdüğünü sordum ve birimin boyutunun 30 TB olduğu söylendi. En son güncelleme aldığımda Şubat ayındaydı ve en son sorguma cevap vermediler.

Fsck'in bazı dosya sistemleri için çok yavaş olabileceğini anlıyorum, ancak fsck'in 30 TB'lık bir hacimde 6 ay alması mümkün mü yoksa bu hosting şirketinin bana yalan söylediğini varsaymalı mıyım, böylece her faturamı ödemeye devam ediyorum ay?

fsck

— Brian Bi
kaynak

Muhtemelen en başından beri sana yalan söylüyorlardı. Bunun saatler sürmesini beklerdim . Aralık ayında ödemeyi durdurmalıydın.

— Michael Hampton

Yalan değil bile, bir HW + yazılımı kurulum seçerek o olabilir bir fsck uzun gösterileri onlar ediyoruz beceriksiz gerektirir. Nedeni ne olursa olsun, ödediğiniz hizmeti vermiyorlar.

— Peter Cordes

Gerçek bir küme fsck gibi geliyor!

— JMK

@JMK Şimdi daha fazla liyakat için yorumları işaretlemenin bir yolu olsaydı, belki bir şöhret salonuna ekleyin.

— boru

@PeterCordes'ın söylediği anahtar nokta. Bir hizmet için para ödüyorsunuz. Sorun yaşadıklarını duyduğunuz için gerçekten üzgünüz, ancak ödediğiniz ve almamanız gereken hizmeti çağırıyorsunuz.

— Rob Moir

Yanıtlar:

fsckhız esas olarak dosya sayısına ve bunların ilgili dizine nasıl yayıldığına bağlıdır. Bununla birlikte, a için 6 ay fsckkesinlikle saçma: özellikle xfshızlı bir hizmete sahipse, en fazla birkaç saat içinde tamamlanmış olmalıydı xfs_repair. Buradafsck bir ölçekte bir koşu bulabilirsiniz - hepsi bir saatin altında (3600s) tamamlandı. Yani, fsckhala çalışıyor olması mümkün değil .

Neyse, beklenmedik bir güç kaybı olacak değil tam bir darbe neden fsckyerine sadece çok hızlı (bazı saniye) dergi tekrarını . Ancak, bazı önemli dosyalar zarar görmüşse, işletim sistemi önyükleme yapılamayabilir.

Ama muhtemelen sana yalan söylediler. Hemen ödemeyi durdurmalı, bir açıklama istemeli ve toplam geri ödeme için başvurmalısınız.

— shodanshok
kaynak

Eğer kullanıyorlarsa ext2, bir elektrik kesintisi tam bir gerektirir fsckve yoğun olarak kullanılan 30 TB'lık bir hacimde günler alırsa şaşırmam. Öte yandan, 30 ext2TB'lık bir birim kullanıyorlarsa , kendi başına barındırma hizmetleri için başka bir yere bakmak için bir neden.

— Mark

ext2, 32-bit blok sayacı kullanır ve x86 ve x86_64 üzerinde maksimum 4096 bayt blok boyutu (yani: bir sayfa) kullanır. Bu, ext2'nin (ve ext3'ün) 8 TB'lık birimlerle sınırlı olduğu anlamına gelir, bu nedenle OP, ext2 / 3 kullanamaz. Her neyse, günlüksüz bir dosya sistemini 30 TB'lık bir birimde kullanmak kesinlikle delilik olur .

— shodanshok

Bence çok sayıda küçük dosya içeren 30 TB FS varsa ext4 fsck biraz daha iyi olabilir. Bunu yaratmak için bir şans, bu yüzden başka bir yere bakmak için hala bir neden.

— nigel222

Konjektif: Sistemlerinde, minimum maliyetle maksimum performans elde etmek için mümkün olan tüm yazma önbellekleri (sabit disklerde bulunanlar dahil) BBU / FBWC'siz RAID (hatta yazılım RAID) kullanılır. Bu tür bir kurulumdaki sabit güç kesintisi, günlüğe güvenilemediği ve kurtarma için kullanılamadığı bir durumda günlük kaydı dosya sistemini bırakabilir. Sorun şu ki, böyle bir sistem agresif bir şekilde yeniden sıralar ve erteler, yani bir günlük girişi, veri eyleminin kaybolması ya da sonuç olarak kaydedilen bir veri eyleminde kaybolmasıyla yazılabilir.

Böyle bir sistemi en kötü durum kesintisinden kurtarmak, aslında tüm dosya sistemi yapılarını olduğu gibi inceleyen "30" için bir ya da iki gün sürebilecek "yavaş" bir fsck / repair yapmanız gerektiği anlamına gelebilir. birden fazla onarım döngüsü yürütmeniz gerekmeyecektir. Buna ek olarak, personel bunu izlemek için her zaman müsait olmayabilir, haftada bir fsck'e kolayca gidebilirsiniz. Muhtemelen vazgeçtiler ve unuttular.

— rackandboneman
kaynak

Çoğu dosya sistemi için, normalde yalnızca meta veriler kontrol edildiğinden, hatalar olsa bile çok daha hızlı olacaktır.

En kötü durumda, tüm diski okuyabilir ( örnfsck.ext4 -cc /dev/sda . Her blokta tahribatsız yazma testi yapan bir şey ), 30 TB için birkaç gün sürebilir. Sürücülerin hızını biliyorsanız, boyutu / hızı hesaplayabilirsiniz . Yaklaşık 100 MB / s kopya alan bir tüketici sabit diski için, birkaç TB'nin çoğunun beklediğinden daha fazla saat sürebilir.

Sunucunuz fsckolsaydı, bir hatayı düzeltmek isteyip istemediğinizi sorduğunda önyükleme yapma sorununa sahip olabilirsiniz . Ancak, fscktüm VPS çevrimdışı iken veri merkezi yöneticisi 6 ay boyunca askıda kalmayacak .

Yani ya size yalan söylüyorlar ya da büyük bir yanlış anlama var. Ya da bir süre önce fsck çalıştırıyorlardı ve bittikten sonra yeni sorun hakkında sizi güncellemediler.

— allo
kaynak

fscktüm dosya sistemi yapılarında gezer, bu da çoğunlukla rastgele g / Ç yürütme anlamına gelir. Dolayısıyla, ardışık aktarım hızına dayanan yukarıdaki hesaplama çok yararlı değildir.

— shodanshok

@shodanshok aslında dosya yapısı genel bir sürücü kontrolünde ilgisiz, cevapta açıkladığım gibi.

— Olağanüstü Zeka

@shodanshok benim en kötü durum varsayım çok geniş bir fsck dayanıyordu. Örneğin, tipik xfs fsck fazla bir şey yapmaz. ext2 uzun süren kapsamlı bir denetime sahiptir ve eski MS-DOS scandisk, tam modda çalıştırırken her sabit sürücü bloğunda bir okuma-yazma testine sahiptir. Böylece diskin boyutunda bir üst sınırınız var.

— allo

@Overmind Ve cevabınız, genel bir sürücü kontrolü değil, fsck ile ilgili soru ile alakasız.

— BlackJack

Bir gösterge olarak tipik disk verimini almanın yanıltıcı olabileceğini lütfen unutmayın. Bir kez yeniden senkronize ederken (bence) bir günden az sürmesi gereken matematik yaptım ve iki hafta sürdü! Aramalar, toplam süre için baskın olan tek faktördür ve kesinlikle sıralı bir işlem yaptığınızı düşündüğünüzde bile , bazen bir değildir. Şimdi fsck kesinlikle sıralı değil, bu yüzden ... normal disk işleminden işlemin uzunluğuna kadar hiçbir şekilde yargılayamazsınız (yine de aylar saçma ... açık bir yalan).

— Damon