Dnia 27.01.2017 Atlantis <m...@w...pl> napisał/a:
> W dniu 2017-01-27 o 22:32, Sebastian Biały pisze:
>
>> uszkodzony *przypadkowy* kawałek filesystemu. Na przykład dowolny plik
>> systemowy. W niektórych modelach kart masz *gwarantowane* trwale i
>> nieodwracalne uszkodzenie jesli nie zamkniejsz poprawnie systemu a
>> wyłączysz zasilanie w trakcie zapisu.
>
> Ja już w ogóle miałem dziwne doświadczenia z kartami pamięci i Raspberry
> Pi. Kiedyś próbowałem odpalić Raspbiana, stosując dopiero co kupioną
> kartę. Nie pamiętam już jaka firma - ani chiński "no name", ani porządny
> SanDisk - raczej coś stojącego w połowie drogi między nimi. Karty tego
> samego typu wcześniej stosowałem już w paru projektach z
> mikrokontrolerami i zawsze działały prawidłowo.
> Zainstalowałem Raspbianna, zaktualizowałem go, zrobiłem jakąś podstawową
> konfigurację i wstępnie skonfigurowałem. Już wtrakcie wykonywania
> "apt-get upgrade" zaczął sypać błędami. Po restarcie już nie wstał -
> błąd systemu plików.
> Druga karta tego samego typu zachowała się w dokładnie ten sam sposób.
>
>
>> PS. Tak, znam ludzi którym to się nigdy nie przytrafiło. Ale to bardziej
>> kwestia ich szczęscia.
>
> Mi już raz system plików na Raspberry Pi wysypał się przy okazji awarii
> zasilania...
>

Jak padają, to nic nie poradzisz. Duża pewność, że system plików zawsze
został przemontowany w tryb read-only.
Wystarczy choćby SysRq+s,u lub
echo s > /proc/sysrq-trigger
echo u > /proc/sysrq-trigger

Maksymalne ograniczenie liczby jakichkolwiek bezpośrenich zapisów.
Sprawdzasz co, gdzie i kiedy zapisuje:
echo 1 > /proc/sys/vm/block_dump
i zatrzymujesz
echo 0 > /proc/sys/vm/block_dump

Maksymalnie duże wartości (10 minut - 60000) w
/proc/sys/vm/dirty_writeback_centisecs
/proc/sys/vm/dirty_expire_centisecs
Stosowanie Zram, overlafs i sto innych tricków.