System plików karty SD odporny na uszkodzenia dla wbudowanego systemu Linux?

Ostatnio mieliśmy raczej nieprzyjemną sytuację z naszym klientem - „kiosk” oparty na Raspberry Pi używany do wyświetlania danych z teledetekcji (nic bardziej wymyślnego niż przeglądarka w trybie kiosku wyświetlająca stronę z aktualizacją z serwera gromadzącego dane) nie uruchomiła się z powodu uszkodzenie systemu plików. Ext4, wymagana instrukcja fsck, system będzie częścią jutrzejszej ważnej prezentacji, usługa wymagana natychmiast. Oczywiście nie możemy wymagać od klienta dobrego zamykania systemu podczas wyłączania go na noc; system musi po prostu wytrzymać takie złe traktowanie.

Chciałbym uniknąć takich sytuacji w przyszłości i chciałbym przenieść system operacyjny do systemu plików, który by temu zapobiec. Istnieje wiele systemów plików przeznaczonych dla urządzeń MTD, w których uruchomienie ich na karcie SD (standardowe urządzenie blokowe) wymaga poważnych skoków. Istnieją również inne systemy plików (dzienniki itp.), Które oferują dobrą odporność na uszkodzenia. Nadal muszę zobaczyć rozsądne porównanie ich zalet i wad.

Który system plików dostępny w Linuksie zapewni najlepszą odporność na uszkodzenia w przypadku nieoczekiwanych awarii zasilania i nie będzie wymagał przeskakiwania przez niemożliwe obręcze, takie jak yaffs2 , aby zainstalować się na karcie SD.

Równoważenie zużycia jest zaletą, ale nie jest wymogiem - karty SD mają zwykle własne mechanizmy, choć mniej niż doskonałe, chociaż system powinien być „łagodny dla flashowania” (systemy takie jak NTFS mogą zamordować kartę SD w ciągu miesiąca).

Najlepsza odporność na uszkodzenie na pojedynczej karcie SD byłaby oferowana przez BTRFS w trybie RAID1 z automatycznym szorowaniem uruchamianym co określony czas.

Korzyści:

1. zachowując zdolność RW do systemu plików
2. nowoczesny, w pełni funkcjonalny system plików z bardzo przydatnymi opcjami dla RPi, takimi jak przezroczysta kompresja i migawki
3. zaprojektowany z myślą o pamięci flash (między innymi)

Oto jak to zrobić:

Pracuję na moim RaspberryPi na Linuksie ArchARM, a moja karta znajduje się w czytniku SD, więc odpowiednio zmodyfikuj te instrukcje dla innych dystrybucji i / dev interfejsów.

Oto przykładowy układ partycji:

/dev/mmcblk0p1: fat32 boot partition
/dev/mmcblk0p2: to be used as btrfs partition
/dev/mmcblk0p3: to be used as btrfs partition (mirrored with the above)
/dev/mmcblk0p4 (optional): swap

Aby dostać btrfs do RAID1, tworzysz system plików w następujący sposób:

mkfs.btrfs -m raid1 -d raid1 /dev/mmcblk0p2 /dev/mmcblk0p3

Następnie przejdziesz rsync -aAXvdo wcześniej utworzonego systemu kopii zapasowej.

Aby go uruchomić z BTRFS w raid1, musisz zmodyfikować initramfs . Dlatego musisz wykonać następujące czynności, dopóki system działa na starym systemie plików.

Raspberry zwykle nie używa mkinitcpio, więc musisz go zainstalować. Następnie musisz dodać „btrfs” do tablicy MODULES w mkinitcpio.conf i odtworzyć initramfs za pomocą

mkinitcpio -g /boot/initrd -k YOUR_KERNEL_VERSION

Aby wiedzieć, co wpisać zamiast YOUR_KERNEL_VERSION, uruchom

ls /lib/modules

Jeśli zaktualizujesz jądro, MUSISZ odtworzyć initramfs PRZED ponownym uruchomieniem.

Następnie musisz zmodyfikować pliki rozruchowe RPi.

W cmdline.txt musisz mieć

root=/dev/mmcblk0p2 initrd=0x01f00000 rootfstype=btrfs

i w config.txt musisz dodać

initramfs initrd 0x01f00000

Po wykonaniu wszystkich tych czynności i pomyślnym uruchomieniu systemu RAID1 w btrfs, jedyne, co pozostało, to skonfigurować okresowe czyszczenie (co 3-7 dni) za pomocą systemowego timera (preferowane) lub cron (dcron) w następujący sposób:

btrfs scrub start /

Będzie działał na twoim systemie plików, porównując sumy kontrolne wszystkich plików i naprawiając je (zastępując poprawną kopią), jeśli znajdzie jakieś uszkodzenie.

Połączenie BTRFS RAID1, single medium i Raspberry Pi sprawia, że ​​jest to dość tajemnicze urządzenie. Zebranie wszystkich elementów zajęło trochę czasu, ale oto jest.

Pamięć flash jest bardziej pożądana niż pamięć magnetyczna z wielu powodów, ale dla tej aplikacji powiem głównie, ponieważ nie ma ruchomych części. To powiedziawszy, nie sądzę, że istnieje system plików „odporny na uszkodzenia”, ale istnieją pewne solidne systemy plików (ext4 to jeden), a także pewne taktyki, które pomogą złagodzić korupcję.

Dysk RAM

Jeśli obraz RPi nie musi się zmienić, a wygląda na to, że tak nie jest, jeśli nic nie będzie próbowało (lub powinno próbować) zapisywać na dysku, spróbuj użyć systemu plików root utworzonego w celu rozpakowania do pamięci RAM . Chodzi o to, że podczas uruchamiania masz skompresowany główny system plików, który jest rozpakowywany do pamięci RAM. Wszystkie zmiany zachodzą na dysku RAM, więc zapisywanie na karcie SD jest zerowe, tylko odczyt przy rozruchu. powinno to ograniczyć liczbę odczytów / zapisów na dysku, zachowując jego żywotność. Jest to podobne do tego, co dzieje się podczas uruchamiania systemu Linux z dysku CD i jest jedną z pierwszych rzeczy, które mają miejsce po uruchomieniu systemu Linux .

Wybrałbym inną drogę i używałbym systemu plików tylko do odczytu. Nigdy nie dostaję mojej Raspberry Pi wystarczająco stabilnej, gdy korzystam z głównego systemu plików do odczytu i zapisu na karcie SD. Możesz po prostu uruchomić swój root za pomocą jądra cmdline (ro) lub użyć initramfs z piggyback, w tym całego systemu.

Oba są możliwe do utworzenia za pomocą mojego domowego systemu kompilacji OpenADK. ( http://www.openadk.org )

Problem polega na tym, że użycie „nowoczesnego” systemu plików, takiego jak ext *, może spowodować uszkodzenie karty SD; z mojego doświadczenia, które wydarzy się w ciągu roku lub następnego roku, jeśli weźmiesz wyższy koniec.

Problem polega na tym, że nowoczesne systemy plików zawsze przesuwają bloki, aby zapobiec fragmentacji danych. Co jest dobre w spinningowych dyskach, gdzie chcesz, aby wszystkie dane były zestawiane podczas ładowania do pamięci podręcznej. Minusem jest to, że wykonuje więcej zapisów, których nie można zapisać w pamięci podręcznej, ponieważ porządkowanie jest obsługiwane, gdy nie dzieje się wiele operacji we / wy.

Dzieje się tak również wtedy, gdy wykonujesz dużo rejestrowania, co możesz chcieć zrobić podczas debugowania urządzenia osadzonego. Zapisywanie w dzienniku jest najgorszym rodzajem zapisu, ponieważ regularnie dzieje się wiele drobnych zapisów, co powoduje dużą fragmentację.

Jak mówisz, twój system obsługuje również dane czujnika, jest bardzo prawdopodobne, że przechowujesz je w pamięci flash, gdy tylko się pojawią. I są tak złe, jak dane dziennika.

Wpadłem na ten sam problem, na który napotykasz, i oto moje wnioski. Próbowałem poszukać kart SD, które byłyby sprzedawane jako „bardziej niezawodne”, tj. Zdolne do obsługi większej liczby zapisów niż inne, ale nie znalazłem na rynku żadnego testu porównawczego, który by się na tym skupiał, w przeciwieństwie do testów porównawczych na dysku SSD. Ponieważ wszystkie koncentrują się wyłącznie na prędkości, nie można poznać liczby zapisów na blok pamięci i technologii zastosowanej w karcie SDCard.

Zauważyłem jednak, że sandiski klasy „przemysłowej” miały dłuższą żywotność, której nie wymieniono. Co nie jest zaskakujące, gdy płacisz więcej, dostajesz więcej.

Ale w końcu, przy włączonym intensywnym logowaniu, nie znalazłem żadnej karty SD o żywotności dłuższej niż kilka lat, przy czym jeden rok jest najbardziej śmiertelny.

Rozwiązaniem, które wymyśliłem, są rozwiązania @ BigHomie i @wbx: użyj systemu plików extX tylko do odczytu (ponieważ dziennikowanie nie jest już potrzebne, możesz nawet wrócić do starego dobrego ext2). A jeśli chcesz przechowywać dzienniki w sesji lub zapisywać pliki tymczasowe, zawsze możesz użyć RAMDISK.

Istnieją tylko samouczki i skrypty, które pomagają zapełnić ramdysk danymi z części tylko do odczytu, dzięki czemu można je edytować w sesji.

Uwaga: z mojego doświadczenia wynika, że ​​korzystam z Angstrom Linux na Beaglebone, wśród próbnych 20 urządzeń z czujnikami. Rejestrowanie tego systemu było bardzo szczegółowe, przy użyciu systemu dziennika systemd.

Linux oferuje wiele systemów plików. ext4 jest tym, w co mam większe zaufanie. W razie wątpliwości, ext4 powinien być używany dla każdej partycji, która zostanie zamontowana do odczytu i zapisu.

System plików ext2 jest znacznie bardziej delikatny. Jest to doskonale dobry system plików dla systemów, które są w stanie zamontować go w trybie tylko do odczytu lub poprawnie odmontować. Ale uszkodzenie jest niezwykle prawdopodobne w przypadku awarii zasilania na ext2 .

Inną opcją może być rozważenie jfs, chociaż system plików jfs nie jest niezawodny w niektórych wersjach systemu Linux. Korupcja jest mniej prawdopodobna w przypadku jfs niż w przypadku ext4 . Jfs ma również szybki czas montowania i czas sprawdzania systemu plików.