badblocks 8 TB+ disklerde anında çöküyor: 32-bit blok limiti ve -b 4096 çözümü

dev.to'da yayınlanan bir yazı, köklü Linux disk test aracı badblocks'taki sessiz bir hata modunu ele alıyor: modern ve büyük bir diske yönlendirildiğinde, tek bir bloğa bile dokunmadan çıkabiliyor; disk test edilmemiş kalıyor ve işi arka plana attıysanız tamamen fark edilmiyor.

Yazının yazarı, Fin bir seedbox ve depolama barındırıcısı olan Pulsed Media'da günlük altyapı işlerini yürüten otomatik bir sistem yöneticisi olarak tanımlanıyor ve soruna yenilenmiş 18 TB diskleri test ederken (burn-in) rastlamış. badblocks -wsv /dev/sdb olarak başlatılan yıkıcı bir yaz-doğrula geçişi, bir saniyenin altında komut istemine geri dönmüş ve şu mesajı vermiş: 'Value too large for defined data type invalid end block (7812500000): must be 32-bit value'. Ne bir ilerleme çubuğu, ne ilk geçiş; hiçbir şey yazılmamış ya da doğrulanmamış.

32-bit blok sayısı tavanı

dev.to yazısına göre badblocks diskleri bloklar halinde adresliyor, blok numaralarını 32-bit bir tamsayıda tutuyor ve varsayılan blok boyutu 1 KiB. Bu yüzden blok sayısı 2^32'nin, yani yaklaşık 4,29 milyarın altında kalmak zorunda; bu da adreslenebilir cihazı kabaca 4,4 TB ile sınırlıyor. 1 KiB birimleriyle sayılan 8 TB'lık bir disk yaklaşık 7,8 milyar blok ediyor ve limiti fazlasyla aşıyor; araç da kurulum aşamasında çalışmayı reddediyor. Hatanın kısmi bir geçiş değil de anında olmasıının nedeni bu: sayaç, ilk blok bile okunmadan taşıyor.

-b 4096 geçmek

Çözüm tek bir bayrak: blok boyutunu sayı sığana kadar yükseltmek. badblocks -b 4096 -wsv /dev/sdX aynı 8 TB'lık diski yaklaşık 1,95 milyar blok olarak sayıyor ve tavanın güvenle altında kalıyor. Boyut limiti blok boyutuyla ölçeklendiğinden, 4 KiB bloklar yaklaşık 17,6 TB'ye kadar cihazları kapsıyor; yazıya göre bu da günümüzde satılan neredeyse her şey demek. Yaklaşık 20 TB'den sonra -b 8192 ve üzerine geçin; önerilen pratik kural, badblocks sayımı kabul edene kadar blok boyutunu ikiye katlamaya devam etmek.

Yazar ayrıca 4 KiB'nin herhangi bir büyük diskte doğrudan varsayılanınız olması gerektiğini savunuyor. Modern disklerin zaten kullandığı fiziksel sektör boyutuyla eşleşiyor ve yazıya göre 1 KiB erişimlerden daha hızlı; yani bir dezavantajı yok.

Arka plana atmak hatayı nasıl gizliyor

Yazıya göre hikayenin daha maliyetli kısmı sayısal değil operasyonel. 18 TB'lik bir diskte yaz-doğrula geçişi günler sürüyor; doğal refleks nohup badblocks -wsv /dev/sdb > /root/sdb.log 2>&1 & komutunu verip uzaklaşmak. Ama blok sayısı taşması tetiklenirse, badblocks hatasını yazdırıp ilk saniye içinde çıkıyor ve nohup bu hatayı kimsenin izlemediği bir log dosyasına yönlendiriyor. Yarım bitmiş bir burn-in beklerken geri dönüyor, diske hiç dokunulmadığını görüyorsunuz; shell geçmişine göre iş çalışmış sayılıyor.

Yazı bunun yerine iki alışkanlık öneriyor. Burn-in'i nohup yerine screen ya da tmux altında çalıştırın ve sürecin kurulumdan gerçekten sağ çıktığını doğrulayın — bir disk grubunda sleep 4; pgrep -c badblocks, başlatılan disk sayısına eşit bir değer döndürmelidir; sıfır, hepsinin başlangıçta öldüğü anlamına gelir. Ve bir saniyede biten bir burn-in'i tamamlanmış değil, başarısız bir çalışma olarak değerlendirin.

sd? glob'u da diskleri kaçırıyor

Aynı yazıda ilgili bir sayım tuzağı daha var: sd? shell glob'u yalnızca tek harfli cihaz adlarını, sda'dan sdz'ye kadar eşleştiriyor. Çok sayıda disk ve HBA barındıran yoğun bir makinede çekirdek sdaa ve sdab gibi iki harfli adlar atamaya başlıyor ve glob bunları sessizce atlıyor — yani her diski kapsaması amaçlanan bir döngü bazılarını sessizce yok sayıyor. Önerilen alternatif, lsblk -dn -o NAME,SIZE,TYPE | awk '$3=="disk"{print $1}' ile saymak; bu komut cihaz adının ne kadar uzadığını umursamıyor ve harf tahmin etmek yerine bildirilen boyuta göre filtreleme yapmanıza izin veriyor.

Neden önemli

-w ile badblocks, diskleri gerçek veri taşımadan önce elemek için tam da bu yüzden kullanılan yıkıcı, her şeyi yazan bir test — yazının bağlamı, müşteriler ona güvenmeden önce yenilenmiş diskleri doğrulayan bir barındırıcı ve -wsv'nin işaret ettiği her şeyi sildiği uyarısı yapıyor. Başlangıçta ölen bir çalışma hiçbir sinyal üretmez: görebileceğiniz bir konsol hatası yok, kısmi sonuçlar yok, sadece sessiz bir hiç. Marginal bir diski yakalamak ile onu servise koymak arasındaki fark tam olarak bu. Daha geniş ders, uzun süren her altyapı işi için geçerli: başlatmadan sonraki saniyelerde sürecin hayatta olduğunu doğrulayın, çünkü anında bir çıkış, bitiş kıyafeti giymiş bir başarısızlıktır.