Asla bozulmayan dosya sistemi (veri kaybı kabul edilebilir)

Bu konunun etrafında dönen birkaç konu var, ancak aradığım şey biraz farklı. Gömülü bir Linux üzerinde bir SD kartım var ve güç kaybından muzdarip. Donanımı bir noktada değiştirebilirim, düzgün şekilde kapatıp vb. Yapabilirim. Ama şu anda sadece karışıklık olmadan güç kaybından kurtulan bir dosya sistemi bulmak istiyorum. Veri kaybı kabul edilebilir. Şu anda yazdığım dosyadan daha fazlasını kaybetmemeyi tercih ederim, ancak yine de 'bağlayamıyorum', 'bu 10 dakika bekle' veya 'yeni oluşturamıyorum' ile karşılaşmak yerine hepsini kaybetmeyi tercih ederim Bu inode nedeniyle bir şey hatası dosyası. ' Program devam etmeli ZORUNLU!

Bunu sağlamak için çok çaba sarf ediyorum. Endüstriyel sınıf bileşenler kullanıyorum, donanım bekçi köpekleri, yazılım bekçi köpekleri, iç, dış, programları yeniden başlatan init, sürekli belleği kontrol eden cinler, dosya tanımlayıcıları ve neyse, diğer bekçiler tarafından izlenen bekçilerim var ... Ama SD kartın takılabileceğini ve çalışabileceğini garanti edemiyorum?

Şu anki en iyi bahisim, SD kartta JFS kullanmak, kurulumuma fsck ve fsck.jfs eklemektir. (600kb + ekleyerek koçumu ve flaşımı yerken. Bu kötü.) Ve her açılışta fsck'i çalıştırın (belki çok fazla önyükleme süresi ekleyerek. Biraz kötü.). Yine de biraz üzgün görünüyor.

Herkes daha iyi bir yol veya daha iyi bir dosya sistemi biliyor mu?

GÜNCELLEME: e2fsprogs-libs (jfsutils bağımlılığı) benim dağıtımda derlemek çok zor görünüyor. ZFS'ye bakacağım (bu benim dağıtımım için doğal değil. Ve ihtiyacım olmayan çok şey yapıyor gibi görünüyor.)

GÜNCELLEME2: Sistemim ve testlerim hakkında daha fazla bilgi: SD kart depolama alanı ikincil, isteğe bağlı bir depolama birimidir. SD kartlar 2Gb-8Gb endüstriyel sınıf microSD'dir. SD kart, rc-mount'umdan mount -t komutuyla monte edilir. Seçenekler "noatime", ancak "sync" değil. Dağıtımım, 3.10 çekirdeği ve 1.21 meşgul kutusuyla özel bir Analog Aygıt aromalı uClinux'dur. Birincil depolama alanım jffs2 ile bir spi flaş. Bununla ilgili hiç sorun yaşamadım. Kullanılabilir bir fsck.jffs2 olup olmadığını bile bilmiyorum. Diğer yandan nand flash ... ama bu farklı bir hikaye. SD kartın amacı, ölçüm verilerini saklamaktır. 'Monitör' programı sonuçları bir dosyaya ekler ve stratejik senkronizasyon yerleşimlerine sahiptir. Dosya belirli bir boyutun üzerine çıktığında yeni bir dosya oluşturulur. Belirli sayıda dosyaya ulaşıldığında en eski dosya silinir. Mevcut ölçüm dosyası güç kaybı nedeniyle kaybedilirse felaket olmaz. Dosyalar genellikle 50-100kb ve 1 sonuç genellikle 1kb'dir. Bu sadece ilk geliştirme aşamasıdır. Hiçbir şey sabit değil. Bu, gömülü sistemlerde flash olmayan dosya sistemleriyle ilk kez ilgileniyordum. (X86 sunucularımda ext4 aldım.)

Vfat ile başladım. Varsayılan dosya sistemi. (Fabrikaların bunu seçmek için bir nedenleri olabileceğini düşündüm. Ve işler işe yararsa gerçekten o kadar umursamıyorum.) Gömülü vfat aygıtlarımda hiç güç kaybı sorunu görmedim. Ancak WinCE'de FAT ile ilgili sorunlar yaşadım. Ancak, 'monitör' programım 100-200 dosyaya ulaştığında artık oluşturmayı reddetti. FAT'in kökte özel bir dosya sınırı sorunu ve alt dizinlerde biraz daha büyük bir sorunu var gibi görünüyor. 1 dir 500-1000 dosyaları oluşturmak gerekir. Yani vfat yapmaz.

Sonra ext2'ye geçtim. Gerçi başlangıçta bir fsck eklemedim. (Bunu yapmak zorunda olduğumu bilmiyordum.) Bir gün içinde 'monitör' programım 'bir şeyleri inode' hatası nedeniyle daha fazla dosya oluşturamadı. Felaket!

Şu anki çözümüm başlangıçta "e2fsck -y" ile ext2. Şimdiye kadar umut verici görünüyor. Ama e2fsck ve 'başlangıçta fsck' konsepti bana titriyor. Kendisi tarafından e2fsck benim birincil flaş ve ram 350kb daha fazla harcama. (Çalışmıyorken.) Yani bu benim en büyük programım. Meşgul kutusundan daha büyük. Neredeyse çekirdeğime rakip oluyor.

Ext3'ü düşünüyorum. Zarar vermeyen meta verileri günlüğe kaydetti. Yine de ne kadar yardımcı olacağından şüpheliyim. Küçük dosyalarım ve kontrollü senkronizasyonlarım ile kapsanmam gerektiğini düşünüyorum. Sıralı bir yazma sırasına sahiptir. Bu da verilerin bir şekilde günlüğe kaydedildiği anlamına gelir. Ancak bu belirleyici olmayan gecikmelere yol açabilir. Bu benim durumumda kötü. (Bu muhtemelen bir sorun değildir.) Ayrıca zamanlanmış bir senkronizasyon özelliği vardır. Örneğin. her 5 saniyede bir. Sanırım kendi senkronizasyonlarıma müdahale ediyor. SD kartlar için çok fazla yazma kötü. Endüstriyel olanlar bile. Bunu nasıl devre dışı bırakacağımla ilgili herhangi bir belge bulamıyorum. Ve ext3 hala her açılışta fsck'in çalıştırılmasını gerektirir! Ancak ext3 hala bir olasılık.

Ext4. Ext3'ün performans sorunlarının çoğunu düzeltir. Yine de performansa ihtiyacım yok. Ve dağıtımım yerleşik mkfs.ext4 ve fsck.ext4 gibi görünmüyor. Belki de bu bir sorun değildir. Gerçi olabilir. Örneğin. e2progs-libs (jfsutils'e bağımlılık) birçok derleme sorununa sahip gibi görünüyor.

JFS, XFS, BRFSS. Hepsi benim çekirdeğim tarafından destekleniyor. Şu anda kullanıcı alanı araç kutuma dahil edilmedi. Her şey oldukça büyük, karmaşık sistemler gibi görünüyor. Ve hepsi başlangıçta bir 'fsck' eşdeğeri gerektiriyor mu?

Kendi dosya sistemimi de atmayı düşündüm: Her zaman dosya tablosunun 2 kopyasını yaz. Geçerken doğru CRC'ye ve en yeni sıra numarasına sahip olanı seçin. 2 aşamalı yazma dizisi oluşturun. Geçici olarak tahsis edin, taahhütte düzeltme Hiçbir fsck gerekmez. Korkarım ki biraz naif olabilir.

GÜNCELLEME3: BTW, gömülü sistemlerin doğası (en azından bu), özerk, katılımsız, erişilemez olmaları ve yıllarca koşmaları gerektiğidir. Fsck gibi programlar olabilir insan etkileşimi gerektiren beni ürkütüyor.

Buradaki öykünüzde biraz tutarsızlık veya en azından belirsizlik var:

'Bağlanamıyor' ile karşılaşmak yerine hepsini kaybetmeyi tercih ederim, 'bu 10 dakika bekleyin'

- Aslında söylemeseniz de - bunun gerçekten yaşadığınız bir sorun olduğunu ima eder. Ama sonra:

e2fsprogs-libs (jfsutils bağımlılığı) benim dağıtımda derlemek zor gibi görünüyor.

Anlamı hepinizi herhangi fsck yok çünkü, e2fsprogs-libsbir bağımlılık olduğu e2fsprogssağlayan e2fsck. Belki de hala burada bir planlama aşamasındasınız ve sistemi örneğin test ext4etmediniz, ancak bunun yerine JFS ile başlamanız gerektiği sonucuna atladınız mı? Bunun özel bir sebebi var mı?

Ahududu pi değişiminde (pi'nin birincil depolama alanı da bir SD karttır) fark ettim, çoğunluğun (kendim dahil) hiç bu kadar çok olmamış olmasına rağmen, bu tür sorunlarla çok sinirli görünüyor herşey. İlk başta, bunların sistemin temiz bir şekilde kapatılması gerektiğinden habersiz insanlar olduğunu varsaydım, ancak bu açıklandığında kavramak zor bir nokta değil ve sistem düzgün bir şekilde kapatılmış olsa bile bunu bildiren insanlar var .

Zaten elektrik kesintilerini tolere edebilmek için buna ihtiyacınız olduğunu söylemiştiniz (ki bu yeterince adil), ancak bundan bahsediyorum çünkü bazı pis ya da bazı SD kartların ya da her ikisinin bir kombinasyonunun sadece eğilimli olduğunu ima ediyor fiş çekildiğinde veya geri takıldığında düzenli olarak gerçekleşen bazı olaylardan (dalgalanma?) dolayı dosya sistemini bozuyor. Ben de görmedim - ve birçok insanın denemesi için bolca zaman vardı - HERHANGİ birisinin btrfs veya jfs'ye ya da başka bir şeye geçtiklerini söyleyen herhangi bir rapor var ve şimdi sorun çözüldü.

Bununla ilgili diğer gizemli şey, insanlar kabloyu istese bile, bu düzenli olarak kullanılamaz bir dosya sistemine neden olmamalıdır. Kesinlikle bunu bir sürü pi / w yaptım ve yüzlerce kez normal bir linux kutusu olmadan yaptım (güç kesildi, sistem tepkisiz hale geldi, bitkin ve kızgınım, vb.) ve küçük veri kaybı görsem de, hızlı bir fsck'ten sonra kullanılamayan bir dosya sistemini hiç görmedim.

Yine, tüm bu raporların doğru olduğunu varsayalım (neden bu kadar çok insanın yalan söyleyeceğini anlamıyorum), sadece temiz bir şekilde demonte etmekten çok daha fazlası oluyor, ancak yine de küçük bir kullanıcı yüzdesini etkiliyor gibi görünüyor. bir tür ortak donanım hatası.

Pi günü yazdığım -yiçin /forcefsckbir sonraki açılışta otomatik olarak çalıştırılır böylece, bir önyükleme komut ve herhangi bir sorun giderilmiştir bakılmaksızın bu gerekli ya da değil gibi görünüyor olsun. 700 Mhz'lik tek bir çekirdekte bu, ~ 4 GB veri içeren 12 GB dosya sistemi için ~ 10 saniye sürer. "10 dakika" inanılmaz uzun bir süre gibi sesler, Yani zaten "Bu söyledim özellikle olduğunu yazmak için küçük dosya sistemi!".

Ayrıca syncdüzenli aralıklarla aramayı da düşünebilirsiniz .

Son olarak, soruyu , gerçekten karşılaştığınız sorunların daha gerçekçi, spesifik ayrıntıları ve daha az abartı ile güncellemelisiniz. Aksi takdirde, çok fazla deneyime ve potansiyel tavsiyeye sahip insanlar tarafından hızlı bir şekilde atlanacak olan erken bir XY problemine çok benziyor .

Program devam etmeli ZORUNLU!

Bu yaygın bir gerekliliktir ve kararlı bir Sistem seçmek söz konusu olduğunda Linux sistemleri en iyi seçimdir.

Çabalarınız da doğru yöne gitmiyor gibi görünüyor. Ancak kararlı bir sistem elde etmek için ne yapabilirsiniz?

İlk düzeyde dosya sisteminizi geliştirebilirsiniz:

• yournal_data_orderedBir ext3/ext4dosya sisteminde, oluştururken veya üzerinde değişiklik yaparken kullanın tune2fs.
• Kontrol sırasında JFSkullanım ile --replay_journal_only.
• Initscripts'te ayarlayarak otomatik yeniden mağazayı etkinleştirin FSCKFIX=yes.

Bu yeterli değilse, buggy diski monte etmeden sisteminizi önyükleyebilirsiniz. Bunun yerine ramdisk, buggy diskinizi manuel olarak kontrol edip onarırken bir taze oluşturun . Bu ayrıca komut dosyaları tarafından otomatikleştirilebilir.

Bir sonraki aşamada size gömülü sistemden çıkmanız ve Yüksek Kullanılabilirlik ile ilgili bazı konuları okumanız gerekir