Sistem file yang tidak pernah putus (kehilangan data dapat diterima)

Ada beberapa topik yang ada seputar masalah ini, tetapi apa yang saya cari sedikit berbeda. Saya memiliki kartu SD pada Linux tertanam dan menderita kehilangan daya. Saya mungkin dapat memodifikasi perangkat keras di beberapa titik, menutup dengan benar dan sebagainya, dll. Tapi sekarang, saya hanya ingin menemukan sistem file yang selamat dari kehilangan daya tanpa repot. Kehilangan data dapat diterima. Saya lebih suka tidak kehilangan lebih banyak daripada file yang saat ini saya tulis, tetapi saya lebih suka kehilangan semuanya daripada menghadapi 'tidak dapat me-mount', 'tunggu 10 menit fsck' atau 'tidak dapat membuat yang baru file karena kesalahan sesuatu sesuatu inode ini '. Program HARUS berjalan!

Saya berusaha keras untuk memastikan ini. Saya menggunakan komponen kelas industri, saya mendapat pengawas perangkat keras, pengawas perangkat lunak, internal, eksternal, init memulai kembali program, daemon terus-menerus memeriksa memori, deskriptor file dan yang lainnya, saya mendapat pengawas menonton pengawas saya, yang pada gilirannya ditonton oleh pengawas lain ... Tapi sepertinya saya tidak dapat menjamin bahwa kartu SD dapat dipasang dan berfungsi?

Taruhan terbaik saya saat ini, adalah menggunakan JFS pada kartu SD, sertakan fsck dan fsck.jfs di instalasi saya. (Menambahkan 600kb + memakan ram dan flash saya. Mana yang buruk.) Dan jalankan fsck di setiap startup (mungkin menambahkan banyak waktu boot. Yang agak buruk.). Sepertinya agak sedih.

Adakah yang tahu cara yang lebih baik atau sistem file yang lebih baik?

UPDATE: e2fsprogs-libs (ketergantungan ke jfsutils) tampaknya sangat sulit untuk dikompilasi dalam distribusi saya. Saya akan melihat ke ZFS (itu bukan asli distribusi saya. Dan sepertinya melakukan banyak hal yang tidak saya butuhkan.)

UPDATE2: Beberapa info lebih lanjut tentang sistem saya dan pengujian saya: Penyimpanan kartu SD adalah penyimpanan opsional sekunder. Kartu SD adalah microSD 2Gb-8Gb kelas industri. Kartu SD dipasang melalui rc saya dengan perintah mount -t. Pilihan "noatime" tetapi tidak "sync". Distribusi saya adalah Perangkat Analog khusus rasa uClinux, dengan kernel 3,10 dan kotak sibuk 1,21. Penyimpanan utama saya adalah spi flash dengan jffs2. Saya tidak pernah memiliki masalah dengan itu. Saya bahkan tidak tahu apakah ada fsck.jffs2 yang tersedia. Nand flash di sisi lain ... tapi itu cerita yang berbeda. Tujuan dari kartu SD, adalah untuk menyimpan data pengukuran. Program 'monitor' akan menambahkan hasil ke file dan memiliki penempatan sinkronisasi strategis. Ketika file datang di atas ukuran yang diberikan, baru akan dibuat. Ketika sejumlah file telah tercapai, file terlama akan dihapus. Jika file pengukuran saat ini hilang karena kehilangan daya, itu bukan bencana. File-file biasanya di 50-100kb dan 1 hasil biasanya 1kb. Ini baru tahap pengembangan awal. Tidak ada yang diperbaiki. Ini adalah pertama kalinya saya berurusan dengan filesystem non-flash di embedded system. (Saya mendapat ext4 di server x86 saya.)

Saya mulai dengan vfat. Sistem file default. (Saya menduga bahwa pabrik mungkin memiliki alasan untuk memilihnya. Dan jika semuanya berfungsi, saya tidak terlalu peduli.) Saya belum pernah melihat masalah kehilangan daya pada perangkat vfat yang tertanam. Saya pernah mengalami masalah dengan FAT di WinCE. Namun, ketika program 'monitor' saya mencapai 100-200 file, ia menolak untuk membuat lagi. Tampaknya FAT memiliki masalah batas file khusus di root dan yang sedikit lebih besar di sub dir. Saya harus dapat membuat 500-1000 file dalam 1 dir. Jadi vfat tidak akan melakukannya.

Lalu saya beralih ke ext2. Saya tidak memasukkan fsck saat startup. (Tidak tahu saya harus melakukannya.) Dalam sehari program 'monitor' saya tidak dapat membuat lebih banyak file karena kesalahan 'inode something sesuatu'. Bencana!

Solusi saya saat ini adalah ext2 dengan "e2fsck -y" saat startup. Sejauh ini sepertinya menjanjikan. Tapi e2fsck dan seluruh konsep 'fsck saat startup' mengganggu saya. E2fsck sendiri menghabiskan lebih dari 350kb flash dan ram utama saya. (Ketika itu tidak berjalan.) Yang berarti itu adalah program terbesar saya. Ini lebih besar dari busybox. Hampir menyaingi kernel saya.

Saya sudah mempertimbangkan ext3. Itu memiliki meta data jurnal, yang tidak akan sakit. Saya ragu seberapa banyak itu akan membantu. Dengan file-file kecil saya dan sinkronisasi yang dikontrol, saya pikir saya harus ditanggung? Ini memiliki urutan penulisan yang diurutkan. Berarti data juga agak jurnal. Namun ini dapat menyebabkan keterlambatan non-deterministik. Yang buruk dalam situasi saya. (Ini mungkin bukan masalah.) Ini juga memiliki fitur sinkronisasi terjadwal. Misalnya. komit setiap 5 detik. Yang mengganggu sinkronisasi saya sendiri saya pikir. Terlalu banyak menulis buruk untuk kartu SD. Bahkan yang industri. Saya tidak dapat menemukan dokumentasi tentang cara menonaktifkan ini. Dan ext3 masih membutuhkan fsck untuk dijalankan di setiap startup! Namun ext3 masih memungkinkan.

Ext4. Akan memperbaiki banyak masalah kinerja ext3. Saya tidak benar-benar membutuhkan kinerja. Dan distribusi saya tampaknya tidak memiliki mkfs.ext4 dan fsck.ext4 bawaan. Mungkin itu bukan masalah. Itu mungkin. Misalnya. e2progs-libs (ketergantungan pada jfsutils) tampaknya memiliki banyak masalah kompilasi.

JFS, XFS, BRFSS. Semua didukung oleh kernel saya. Saat ini tidak termasuk dalam kotak alat ruang pengguna saya. Semua tampaknya sistem yang agak besar dan rumit. Dan mereka semua tampaknya membutuhkan 'fsck' yang setara pada saat startup?

Saya juga mempertimbangkan untuk membuang sistem file saya sendiri: Selalu menulis 2 salinan tabel file. Saat melintasi, ia memilih yang memiliki CRC yang benar dan nomor urut terbaru. Buat urutan penulisan 2 tahap. Alokasikan sementara, perbaiki pada komit. Tidak perlu fsck. Aku takut itu mungkin agak naif.

UPDATE3: BTW, sifat embedded system (setidaknya ini) adalah mereka otonom, tanpa pengawasan, di luar jangkauan, dan mereka harus berjalan selama bertahun-tahun. Program seperti fsck yang mungkin membutuhkan interaksi manusia membuat saya takut.

Ada sedikit ketidakkonsistenan atau setidaknya, ambiguitas, dalam cerita Anda di sini:

Saya masih lebih suka kehilangan semuanya daripada menghadapi 'tidak dapat me-mount', 'tunggu 10 menit fsck'

Tersirat - meskipun Anda tidak benar-benar mengatakannya - bahwa ini adalah masalah yang sebenarnya Anda alami. Tapi kemudian:

e2fsprogs-libs (ketergantungan pada jfsutils) tampaknya sangat sulit untuk dikompilasi dalam distribusi saya.

Berarti Anda tidak memiliki fsck sama sekali , karena e2fsprogs-libsmerupakan ketergantungan e2fsprogsyang menyediakan e2fsck. Jadi mungkin Anda masih dalam tahap perencanaan di sini dan bahkan belum menguji sistem dengan, misalnya ext4, tetapi langsung melompat ke kesimpulan bahwa Anda harus mulai dengan JFS? Apakah ada alasan khusus untuk itu?

Saya perhatikan pada pertukaran pi raspberry (penyimpanan utama pi juga merupakan kartu SD) bahwa sejumlah besar pengguna tampaknya sangat frustrasi dengan masalah seperti ini, meskipun mayoritas (termasuk saya) tidak pernah memilikinya di semua. Pada awalnya saya berasumsi bahwa ini adalah orang-orang yang tidak mengetahui fakta bahwa sistem harus dimatikan secara bersih, tetapi itu bukan hal yang sulit untuk dipahami ketika dijelaskan, dan ada orang yang melaporkannya meskipun sistem TELAH dimatikan dengan benar .

Anda sudah mengatakan Anda perlu ini untuk dapat mentolerir pemadaman listrik (yang cukup adil), tapi saya menyebutkan ini karena itu berarti ada beberapa pis, atau beberapa kartu SD, atau beberapa kombinasi dari keduanya, yang hanya rawan merusak sistem file karena beberapa peristiwa (lonjakan?) yang terjadi secara teratur baik ketika steker dicabut, atau ketika dimasukkan kembali. Saya juga belum melihat - dan ada banyak waktu bagi banyak orang untuk mencoba - SETIAP laporan seseorang yang mengatakan mereka telah beralih ke btrfs atau jfs atau apa pun dan sekarang masalahnya terpecahkan.

Hal misterius lainnya tentang ini adalah bahkan jika orang menyentak kabelnya, ini seharusnya tidak menghasilkan sistem file yang tidak dapat digunakan. Tentu saja saya sudah melakukannya beberapa kali dengan pi, dan skor jika tidak ratusan kali dengan kotak linux biasa (daya terputus, sistem menjadi tidak responsif, saya lelah dan marah, dll.) dan sementara saya telah melihat kehilangan data kecil, saya belum pernah melihat sistem file rusak sampai tidak dapat digunakan setelah fsck cepat.

Sekali lagi, anggap semua laporan ini benar (Saya tidak melihat mengapa banyak orang berbohong tentang hal itu), ada sesuatu yang lebih banyak terjadi daripada tidak secara sederhana meng-unmount, tetapi tampaknya hanya memengaruhi sebagian kecil pengguna, menyiratkan lagi beberapa jenis cacat perangkat keras yang umum.

Pada pi saya menulis -yuntuk /forcefsckdalam naskah boot, sehingga pada boot berikutnya dijalankan secara otomatis dan masalah tetap, terlepas dari apakah ini tampaknya diperlukan atau tidak. Pada single core 700 Mhz ini membutuhkan ~ 10 detik untuk sistem file 12 GB yang berisi ~ 4 GB data. Jadi "10 menit" terdengar seperti waktu yang sangat lama, terutama karena Anda sudah mengatakan "Ini adalah sistem file kecil untuk menulis!".

Anda mungkin juga mempertimbangkan untuk menelepon syncsecara berkala.

Terakhir, Anda harus memperbarui pertanyaan dengan detail yang lebih faktual dan spesifik dari masalah yang sebenarnya Anda temui, dan lebih sedikit hiperbola. Kalau tidak, itu hanya terlihat seperti masalah XY prematur , yang kemungkinan akan cepat dilewati oleh orang-orang dengan banyak pengalaman dan saran potensial untuk Anda.

Program HARUS berjalan!

Nah ini adalah persyaratan umum dan sistem Linux adalah pilihan terbaik ketika datang untuk memilih Sistem yang stabil.

Upaya Anda tampaknya juga tidak menuju ke arah yang benar. Namun apa yang dapat Anda lakukan untuk mendapatkan sistem yang stabil?

Di tingkat pertama Anda dapat meningkatkan sistem file Anda:

• Gunakan yournal_data_orderedpada ext3/ext4sistem file, saat membuat atau memodifikasi tune2fs.
• Dengan JFSdigunakan --replay_journal_onlysaat memeriksa.
• Aktifkan perbaikan otomatis dengan menetapkan FSCKFIX=yesdalam skrip init.

Jika ini tidak cukup, Anda dapat mem-boot sistem Anda tanpa memasang disk buggy. Alih-alih membuat yang segar ramdisksaat Anda secara manual memeriksa dan memperbaiki disk buggy Anda. Ini juga dapat diotomatisasi oleh skrip.

Di tingkat berikutnya Anda harus meninggalkan sistem tertanam dan membaca beberapa topik tentang Ketersediaan Tinggi