Filesystem apa yang menawarkan perlindungan terbaik untuk mengamankan data terhadap korupsi karena kehilangan daya?


9

Saya menjalankan sistem tertanam kecil uClibcdan busyboxberbasis pada perangkat x86. Saya menggunakan initramfs tetapi saya juga memasang ext3direktori khusus pada perangkat flash ringkas dalam mode IDE yang saya gunakan untuk menyimpan data pencatatan pengukuran yang dibuat oleh aplikasi c ++ yang dibuat khusus. Saya memilih ext3sistem file karena direkomendasikan untuk keamanan terhadap kehilangan daya saat menggunakan drive CF dalam mode IDE dalam beberapa buku yang telah saya baca ( Membangun Sistem Linux Tertanam oleh Karim Yaghmour dan Embedded Linux Primer oleh Christopher Hallinan). Ini sangat penting dan datanya sangat penting.

Namun, karena beberapa komentar dalam pertanyaan saya sebelumnya Kebingungan dengan cara mengembalikan file ext3 yang korup jika pemadaman listrik terjadi selama file menulis , akan tampak bahwa sebenarnya sistem file ini tidak menawarkan jaminan keamanan terhadap korupsi data karena daya kerugian. Jadi saya ingin tahu apakah

  1. Apakah ext3sebenarnya pilihan terbaik untuk pengaturan ini?
  2. Apakah kehilangan daya selama operasi penulisan disk hanya merusak sebagian data yang saya tambahkan ke file secara berkala atau dapatkah merusak seluruh file?
  3. Apakah data yang tidak ditulis pada titik kehilangan daya benar-benar aman? Secara khusus, apakah ada risiko initramfs.cpiofile saya bisa rusak juga?
  4. Apakah ada metode apa pun yang dapat saya gunakan dalam kode aplikasi saya untuk melindungi data (yaitu membuat partisi tambahan dan menulis data saya ke gambar cermin sehingga selalu ada 2 salinan) - kecepatan bukanlah masalah nyata untuk aplikasi saya sehingga operasi penyalinan yang mahal dapat diterima.

Saya telah melihat dan membaca jawaban untuk pertanyaan terkait ini: Apakah sistem file jurnal menjamin terhadap korupsi setelah kegagalan daya? , tapi itu tidak cukup menutupi beberapa hal yang membingungkan saya.

Saya menyadari bahwa saya mengajukan banyak pertanyaan, tetapi meskipun membaca banyak materi, saya memiliki kegagalan mendasar untuk memahami risiko terhadap data saya jika terjadi kehilangan daya.

Jawaban:


11

Seperti halnya semua hal yang berkaitan dengan keamanan, tidak ada jaminan, tetapi Anda juga perlu menyeimbangkan risiko (dan biaya) dengan probabilitas. Dari pengalaman (dan saya telah menjalankan puluhan * nix boxen sejak zaman kegelapan), saya tidak pernah benar-benar mengalami kerusakan sistem file yang disebabkan oleh daya.

Beberapa mesin ini bahkan berjalan di sistem file non-journalled (biasanya UFs dan ext2). Beberapa dari mereka tertanam, dan beberapa adalah ponsel seperti Nokia N900 - jadi catu daya yang bagus sama sekali tidak dijamin.

Bukan karena korupsi filesystem tidak dapat terjadi, hanya saja kemungkinannya terjadi cukup rendah sehingga tidak perlu membuat Anda khawatir. Namun, tidak ada alasan untuk tidak melakukan lindung nilai taruhan Anda.

Sebagai jawaban atas pertanyaan literal Anda:

  1. Setidaknya buku pertama yang Anda rujuk telah ditulis sebelumnya ext4- ketika penulis menyarankan untuk menggunakan ext3, mereka benar-benar mengatakan 'jangan gunakan sistem file yang tidak stabil atau non-journal seperti ext2'). Coba ext4, ini cukup matang, dan memiliki beberapa opsi yang layak untuk disk yang tidak berputar yang dapat memperpanjang usia pakai perangkat flash Anda.
  2. Kemungkinannya adalah Anda akan kehilangan satu atau dua blok terakhir, bukan seluruh file. Dengan sistem file journal, ini akan menjadi satu-satunya kerugian. Ada beberapa skenario kegagalan di mana saya bisa melihat data acak disemprotkan di seluruh file, tetapi tampaknya hampir sama dengan menghancurkan mikrometeorit melalui perangkat yang disematkan.
  3. Lihat 2. Tidak ada yang 100,00% aman.
  4. Jika Anda memiliki saluran IDE kedua, tempelkan kartu CF kedua di sana dan ambil cadangan sistem file secara berkala. Ada beberapa cara untuk melakukan ini: rsync, cp dump, dd, bahkan menggunakan md(4)(software RAID) perangkat (Anda menambahkan drive kedua kadang-kadang, biarkan sync, lalu keluarkan - jika kedua perangkat hidup sepanjang waktu, mereka menjalankan risiko yang sama korupsi filesystem). Jika Anda menggunakan LVM, Anda bahkan dapat mengambil foto. Untuk perangkat embedded pengumpulan data, saya hanya akan menggunakan solusi ad hoc yang me-mount sistem file kedua, menyalin log data, yang segera meng-unmount-nya. Jika Anda khawatir perangkat memiliki image boot yang bagus, tempel salinan kedua boot manager dan semua image boot yang diperlukan pada perangkat kedua dan konfigurasikan komputer untuk boot dari kedua kartu CF.

    Saya tidak akan mempercayai salinan kedua pada perangkat yang sama karena perangkat penyimpanan lebih sering gagal daripada sistem file yang stabil. Jauh lebih sering, dalam pengalaman saya sejauh ini (di tempat kerja, ada setengah-lelucon pahit tentang peluang yang sangat tinggi dari kegagalan disk Jumat sore. Itu hampir acara mingguan untuk sementara waktu). Apakah disk berputar atau tidak, itu bisa gagal. Jadi simpan telur Anda di dua keranjang jika Anda bisa, dan Anda akan melindungi data Anda dengan lebih baik.

    Jika datanya sangat sensitif, saya akan melakukan kunjungan rutin ke perangkat, menukar CF cadangan dengan yang baru dan reboot, membiarkannya fscksemua sistem file untuk ukuran yang baik.


+1, namun replikasi mengalami masalah yang sama dengan salinan utama - jika Anda mulai menyinkronkan dua perangkat (baik itu melalui RAID atau utilitas tingkat yang lebih tinggi) dan daya padam (saat ada penambahan konstan pada data), Anda akan dapatkan sampah lagi. Apa yang mungkin membantu adalah memiliki RAID1, dari waktu ke waktu mengubah secara fisik salah satu perangkat dan membuat cadangan yang off-line dihapus. Anda harus membekukan FS sebelum menghapusnya, untuk memastikannya konsisten (yaitu membuat snapshot). XFS adalah salah satu sistem file yang memiliki dukungan untuk ini.
peterph

Memang. Seperti yang saya tulis, tidak ada jaminan. Setiap kali Anda menulis data, Anda bisa mengalami korupsi. Orang-orang di electronics.stackexchange.com telah bermain-main dengan superkapasitor dan deteksi berwarna kecoklatan di mana sistem yang tertanam mendapatkan notifikasi bahwa daya padam, dan masih mendapatkan cukup jus untuk membatalkan penulisan. Mungkin. :) Ini semua masalah seberapa besar kemungkinan Anda berpikir tentang potensi bahaya, dan berapa banyak uang / usaha yang ingin Anda keluarkan untuk menghilangkan masalah yang ada (dan mulai mempertimbangkan yang berikutnya).
Alexios

Terima kasih atas jawaban ini. Ini menjelaskan banyak hal bagi saya.
ahli matematika1975

4

Tampak bagi saya bahwa apa yang dapat dicapai oleh implementasi sistem file jika kehilangan daya tiba-tiba terbatas - bagaimanapun juga, itu sebenarnya berinteraksi dengan perangkat keras, jadi apa yang terjadi antara waktu ia mengirim data / instruksi ke perangkat keras dan ketika itu mendapat respons di luar kendali. Jika ada sistem file yang dapat menghindari masalah ini, Anda pasti sudah mendengarnya.

Karena itu, strategi untuk melindungi data penting akan mendapat manfaat besar dari keputusan yang dibuat pada tingkat perangkat keras , misalnya, dengan menggunakan catu daya yang tidak pernah terputus. Mungkin ini tidak begitu layak dalam situasi Anda.

Anda sudah mengatakan kinerja bukan masalah besar, jadi manfaatkan penggunaannya fsync().

Apakah kehilangan daya selama operasi penulisan disk hanya merusak sebagian data yang saya tambahkan ke file secara berkala atau dapatkah merusak seluruh file?

Saya telah menggunakan filesystem extN secara pribadi dan pada server internet lalu lintas rendah-menengah selama bertahun-tahun, dan seperti Alexios saya belum melihat banyak korupsi karena kegagalan daya (walaupun untuk bersikap adil, server memiliki UPS dan saya tidak dapat mengingat salah satu dari mereka benar-benar turun seperti itu). Masalah yang jauh lebih serius adalah korupsi akibat kegagalan perangkat keras, yang sistem file yang berbeda mungkin (sekali lagi) lebih mampu menangani masalah, tetapi (sekali lagi) ini pada dasarnya di luar kendali mereka dan mereka tidak dapat mencegahnya.

Saya kadang-kadang melihat file hilang, atau terpotong ke ukuran nol. Saya kira ada peluang bagus ini bisa dipulihkan entah bagaimana; ini tidak perlu bagi saya karena mereka didukung. Sebagian besar waktu jika ada yang salah sama sekali fscktampaknya menghadapinya.

Apakah data yang tidak ditulis pada titik kehilangan daya benar-benar aman? Secara khusus, apakah ada risiko file initramfs.cpio saya bisa rusak juga?

Saya pikir risikonya benar-benar sangat rendah hanya dari kegagalan daya, kecuali jenis penyimpanan flash korupsi dapat dikenakan karena lonjakan daya yang dapat menyertai kegagalan daya - yang saya tidak punya pengalaman dengan, tetapi mudah-mudahan Anda telah memikirkan dan meneliti ini.

Apakah ada metode yang dapat saya gunakan dalam kode aplikasi saya untuk melindungi data?

Layak mengulangi poin tentang fsync () . Objek C ++ / iostream tidak memiliki metode untuk ini (:: flush dan :: sync bukan fsync), tetapi yang Anda butuhkan hanyalah deskriptor file.


Terima kasih atas jawaban ini juga sangat membantu. Saya memasang partisi yang akan ditulis melalui syncopsi di /etc/fstabfile karena saya mengerti bahwa ini memaksa penulisan terjadi secara sinkron. Saya berasumsi bahwa ini berarti bahwa ketika file saya menulis kode kembali, maka data telah ditulis secara fisik ke disk. Saya mengerti bahwa pemasangan dengan syncdasarnya sama dengan memanggil fsync(my_filedescriptor)setelah menulis. Apakah pemahaman saya tentang ini benar?
ahli matematika1975

@ mathatician1975 Saya kira begitu, ini bukan sesuatu yang saya teliti. IMO, asalkan tidak merepotkan, melemparkan fsync()pada titik yang Anda anggap tepat tidak akan menyakitkan , dan membuat sistem lebih kuat (misalnya, jika perangkat dipasang dengan santai tanpa set sinkronisasi, dll).
goldilocks

1

ZFS jelas merupakan sistem file yang dilindungi dari korupsi oleh desain dan mungkin satu-satunya. Namun, saya tidak yakin tentang ketersediaan implementasi ZFS (baik berbasis sekering atau asli) untuk platform berbasis uClinux.


0

Setidaknya ada satu sistem file komersial yang melakukan pekerjaan luar biasa memastikan bahwa sistem file hampir tidak dapat rusak karena kegagalan daya dan bahwa satu-satunya data Anda berisiko kehilangan adalah data yang sedang ditambahkan ketika daya padam.

Sisi buruknya adalah harganya sangat mahal, di sisi atas mereka menawarkan dukungan besar. Karena biaya, itu benar-benar hanya pilihan untuk taruhan tinggi dan / atau produk volume tinggi. Seperti peralatan tertanam yang penting dalam mis. Produksi minyak dan gas yang perlu memastikan integritas sistem dalam kondisi operasi yang "tidak pasti" (mis. Pemadaman listrik yang sering, dll.).

Lihat DataLight (perusahaan) dan / atau produk " Reliance NITRO ". (Reliance adalah warisan mereka dan aman tetapi bukan solusi yang sangat efektif, digantikan oleh Reliance NITRO ). Bahkan jika Anda tidak punya uang untuk menggunakan sistem ini, mereka memiliki beberapa artikel yang cukup bagus membahas bagaimana sistem mereka bekerja, mengapa lebih dapat diandalkan daripada misalnya ext3 dan ext4.

Saya minta maaf jika ini dibaca seperti iklan, hanya ingin menunjukkan opsi.


Hai dan selamat datang di situs ini. Jika Anda akan menyarankan produk, silakan i) memberikan tautan ke produk yang dimaksud; ii) menjelaskan mengapa itu lebih baik daripada alternatif (Anda hanya mengklaim itu melakukan pekerjaan yang luar biasa tetapi tidak menjelaskan mengapa itu lebih baik daripada yang lain); iii) jika Anda berafiliasi dengan perusahaan yang membuat ini, Anda harus membuat itu eksplisit atau dituduh melakukan spam (tidak mengatakan bahwa Anda adalah, hanya kepala).
terdon
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.