Algoritma log lingkaran ringan (seperti filesystem) untuk penyimpanan berbasis flash


8

Saat ini saya sedang mengerjakan proyek yang melibatkan pencatatan cepat dan terus-menerus dari metrik khusus aplikasi selama masa pakai yang panjang. Untuk melakukan ini saya akhirnya menggunakan NXP M0 dan chip 32MiB SPI. Penebangan terus menerus dan perlu bertahan bertahun-tahun di lapangan (10+), dan secara berkala diperiksa oleh manusia untuk melihat kecenderungan tren. Akhirnya buffer terisi dan mulai menimpa data lama yang baik-baik saja. Saya datang dengan algoritma sederhana untuk berjalan di seluruh perangkat flash untuk menemukan kepala saat ini setelah power-up (perangkat dimatikan agak sering di luar kendali saya) sehingga logging hanya dapat melanjutkan di mana ia tinggalkan. Saya hanya bisa dengan kasar memaksa melalui jalan ini dan melakukannya dengan ~ 4 sebagai skenario terburuk.

Ini membuat saya berpikir, apakah ada sistem file log terstruktur yang melayani perangkat flash dan mikrokontroler? JFFS dan semua FS Terstruktur Log terkenal lainnya yang saya bayangkan akan sedikit berat untuk mikrokontroler sederhana (tergantung pada aplikasi tentu saja). Untuk lebih spesifik, saya ingin mengetahui algoritma apa pun yang dirancang untuk secara khusus menjadi log bundar dengan waktu pencarian cepat dan / atau apa pun yang dirancang untuk sistem file "tradisional" pada perangkat flash yang dapat dijalankan pada mikrokontroler. Tradisional dalam pengertian ini setara dengan sesuatu seperti JFFS di mana ada struktur data yang mewakili kumpulan file akses acak yang bisa berubah dalam ruang nama hierarkis.


Apakah FAT32 atau FAT16 pada kartu SD terlalu lambat?
vicatcu

2
Pertanyaan ini sepenuhnya pada topik di sini, tetapi jika Anda tidak mendapatkan respons yang bagus, StackOverflow mungkin bisa membantu. Semoga kami mendapat jawaban yang baik di sini!
Kellenjb

@vicatcu Ini tidak terlalu lambat, untuk konektor kartu SD plus aplikasi saya lebih mahal dan kartu SD bisa kurang dapat diandalkan. Kellenjb Saya tidak yakin di mana harus meletakkannya. Seperti banyak pertanyaan disematkan desain semacam ini jatuh di tengah. Jika tidak berjalan dengan baik di sini saya dengan senang hati akan memindahkannya.
Kris Bahnsen

Apakah ini chip flash mentah? Jika demikian, bagaimana Anda menangani balok mati? Cukup banyak bagian dari implementasi implementasi flash FS dengan dead block. Jika Anda merasa JFFS / JFFS2 terlalu berat, Anda mungkin ingin memeriksa YAFFS. Rasanya seperti sistem file yang sangat sederhana, jadi itu harus cukup ringan.
Leo

Ya itu. Blok buruk tidak mengerikan dalam aplikasi khusus ini karena jangka panjangnya sehingga data yang dikeluarkan hanyalah tren kasar, dan dalam banyak kasus saya ragu logging akan digunakan sama sekali.
Kris Bahnsen

Jawaban:


2

struktur data tali

Saya terpesona dengan struktur data tali. Saya memiliki proyek hobi yang mencoba mengadaptasinya ke mikrokontroler dengan hanya beberapa byte RAM yang terhubung ke memori Flash yang besar, sehingga saya dapat memasukkan dan menghapus dan dengan cara lain mengubah teks panjang variabel dalam file teks berukuran besar. File teks terlalu besar untuk masuk ke dalam RAM. Menghapus bagian terakhir file dan menulisnya kembali ke flash, digeser satu byte, setiap kali saya memasukkan atau menghapus karakter di tengah file teks multi-megabyte, akan terlalu lambat, tetapi struktur data tali dapat melakukan ini lebih cepat. Karena struktur data tali dapat mewakili file panjang variabel akses acak yang dapat berubah seperti potongan panjang tetap yang tidak dapat diubah, tampaknya cocok untuk memori flash - semua pengeditan ditulis dengan cara seperti log bundar. Sayangnya, semua bug belum berhasil di kode saya. :-(

log kronologis tetap-panjang

Saya memang membuat sistem log bundar yang sama bekerja, untuk produk yang saya bantu kembangkan.

Saya hanya menulis catatan panjang tetap satu demi satu, mengisi flash sebagai array melingkar.

(Dengan flash yang benar-benar kosong, saya mulai menulis catatan sekitar 3 blok sebelum akhir array, sehingga saya dapat menguji bungkus melingkar setelah hanya beberapa catatan data yang disimpan, daripada mulai dari catatan nol dan menunggu nilai data sebulan untuk ditulis sebelum mengetahui bahwa ada bug dalam kode bungkus saya).

Saya memastikan selalu ada setidaknya 2 "blok terhapus" yang siap untuk ditulis. Setelah menulis catatan, jika hanya ada 2 "blok terhapus" setelah itu kosong, saya tanpa syarat menghapus blok data tertua - blok ke-3 data tertua setelah 2 "blok dihapus". (Mendekati akhir memori flash, "setelah" berarti "membungkus ke awal memori flash). (Mungkin satu blok terhapus akan memadai - Saya lupa mengapa saya pikir saya perlu setidaknya 2 dan kadang-kadang 3) .

Saya lupa persis berapa banyak catatan yang saya masukkan ke dalam setiap "blok hapus", tetapi saya memastikan bahwa saya tidak pernah memiliki catatan yang mengangkangi dua blok hapus - 2 byte pertama dari setiap blok hapus flash adalah nilai "terhapus" 0xFFFF, atau dua byte pertama dari checksum Fletcher-16 (yang tidak pernah 0xFFFF) di header setiap record.

Itu membuatnya cepat untuk memindai pada saat itu dihidupkan dan menemukan kepala log melingkar - Saya hanya harus melihat dua byte pertama dari setiap blok hapus untuk membedakan antara blok "dihapus" dan "data". (Saya sedikit khawatir tentang "kegagalan daya di tengah menghapus blok" yang menyebabkan dua byte pertama dihapus ke 0xFFFF tetapi meninggalkan byte yang tidak terhapus di tengah blok, jadi saya menulis kode untuk mikrokontroler untuk memeriksa untuk ini dan mulai ulang proses "hapus blok").

Tolong beritahu saya jika Anda menemukan struktur data flash-friendly lain atau sistem file.


Pendekatan Anda terdengar agak mirip dengan pendekatan saya. Saya akan menyarankan menambahkan sedikit twist, meskipun: cadangan beberapa byte di setiap blok untuk menunjukkan bahwa itu sudah "dimulai" dan bahwa itu "penuh". Semua blok kecuali blok yang dihapus harus diprogram "dimulai". Ketika tiba saatnya untuk menghapus blok, atur byte "penuh" pada byte terakhir data, lalu hapus blok, dan kemudian segera atur bit "mulai" dari blok terhapus tertua. Saat memulai, jika Anda melihat bahwa blok "terakhir" adalah "penuh", dan bukannya "mulai", ulangi penghapusan.
supercat

Pendekatan seperti itu mungkin terlihat seperti berlebihan, tetapi jika blok flash dihapus sebagian, byte mungkin untuk secara sewenang-wenang memutuskan untuk membaca FF atau sesuatu yang lain. Fakta bahwa sebuah blok tampak kosong bukanlah jaminan bahwa bit tidak akan "muncul" secara spontan di sana. Jika Anda kehilangan daya saat erase sedang berlangsung, tunggu sebentar saat startup berikutnya dan kemudian ulangi erase bahkan jika blok tampak kosong .
supercat

Terima kasih atas informasinya, saya akan melihatnya sedikit lebih dalam ketika saya benar-benar menekan kode untuk penyimpanan flash dan memberi tahu Anda apa yang terjadi.
Kris Bahnsen

@supercat: Terima kasih, itu sepertinya ide yang bagus.
davidcary

@davidcary: Saya tidak tahu bahwa saya pernah memiliki blok yang tampak benar-benar kosong dan tidak, tetapi saya memiliki blok yang akan menghasilkan hasil yang berbeda pada pembacaan berurutan. Mungkin saja blok itu salah dibaca sebagai kode saya kosong mencoba untuk memprogramnya bagaimanapun, menghasilkan mishmosh aneh dari data yang diprogram baru dan sampah lama yang terhapus-hapus. Bagaimanapun, skenario di mana blok kadang-kadang tampak kosong hampir tidak realistis.
supercat

0

Sudah beberapa tahun tetapi saya ingin menindaklanjuti hal ini kalau-kalau ada yang berkeliaran. Sepertinya ada beberapa proyek saat ini, yang dikelola secara aktif (per Januari 2020) yang merupakan filesystem yang ditujukan untuk mikrokontroler yang ditargetkan pada flash NOR SPI.

Perhatikan bahwa saya belum menguji ini dalam kapasitas apa pun, tetapi mereka melakukan persis apa yang dicari oleh pertanyaan aslinya: "... struktur data yang mewakili kumpulan file akses acak yang dapat diubah ..."

https://github.com/ARMmbed/littlefs - Dibuat oleh ARM, berlisensi BSD

https://github.com/joembedded/JesFs - Tampaknya tidak berlisensi, tetapi sangat khusus dirancang untuk SPI NOR flash.

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.