La migliore resistenza contro la corruzione su una singola scheda SD sarebbe offerta da BTRFS in RAID1 modalità con pulizia automatica eseguita ogni periodo di tempo predefinito.
I vantaggi:
- mantenendo la capacità di RW nel filesystem
- Filesystem moderno e completo con opzioni molto utili per un RPi, come compressione trasparente e istantanee
- progettato pensando alla memoria flash (tra le altre cose)
Ecco come fare:
Eseguo il mio RaspberryPi su ArchARM Linux e la mia scheda è nel lettore SD, quindi modifica queste istruzioni di conseguenza per altre distribuzioni e interfacce /dev.
Ecco un esempio di layout di partizione:
/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
Per inserire btrfs in RAID1, devi creare il filesystem in questo modo:
mkfs.btrfs -m raid1 -d raid1 /dev/mmcblk0p2 /dev/mmcblk0p3
Poi tu rsync -aAXv ad esso il sistema precedentemente sottoposto a backup.
Per avviarlo da BTRFS in raid1, devi modificare initramfs . Pertanto, è necessario eseguire le seguenti operazioni mentre il sistema è ancora in esecuzione sul vecchio filesystem.
Raspberry normalmente non utilizza mkinitcpio quindi è necessario installarlo. Quindi, devi aggiungere "btrfs" all'array MODULES in mkinitcpio.conf e ricreare initramfs con
mkinitcpio -g /boot/initrd -k YOUR_KERNEL_VERSION
Per sapere cosa digitare invece di YOUR_KERNEL_VERSION, esegui
ls /lib/modules
Se aggiorni il kernel, DEVI ricreare initramfs PRIMA di riavviare.
Quindi, devi modificare i file di avvio di RPi.
In cmdline.txt, devi avere
root=/dev/mmcblk0p2 initrd=0x01f00000 rootfstype=btrfs
e in config.txt, devi aggiungere
initramfs initrd 0x01f00000
Una volta che hai fatto tutto questo e hai avviato con successo il tuo sistema RAID1 btrfs, l'unica cosa rimasta è impostare uno scrub periodico (ogni 3-7 giorni) con systemd timer (preferito) o cron (dcron) in questo modo:
btrfs scrub start /
Verrà eseguito sul tuo filesystem confrontando i checksum di tutti i file e correggendoli (sostituendoli con la copia corretta) se rileva danni.
La combinazione di BTRFS RAID1, single medium e Raspberry Pi rende questa roba piuttosto arcana. Ci sono voluti un po' di tempo e lavoro per mettere insieme tutti i pezzi, ma eccolo qui.
Vorrei andare in un altro modo e userei solo un filesystem di sola lettura. Non ottengo mai il mio raspberry pi abbastanza stabile quando utilizzo un filesystem root di lettura-scrittura sulla sdcard. Puoi semplicemente avviare la tua root tramite kernel cmdline (ro) o utilizzare un initramfs con piggyback che include il tuo sistema completo.
Entrambi sono possibili da creare con il mio sistema di build fatto in casa OpenADK.(http://www.openadk.org)
Bene, l'archiviazione flash è più desiderabile dell'archiviazione magnetica, per molteplici motivi, ma per questa applicazione dirò principalmente perché non ci sono parti mobili. Detto questo, non penso che esista un filesystem "a prova di corruzione", ma ci sono alcuni filesystem robusti (ext4 è uno di questi) là fuori, così come alcune tattiche per aiutare a mitigare la corruzione.
Disco RAM
Se l'immagine dell'RPi non ha ha per cambiare, e sembra che non sia così, se nulla proverà a (o dovrebbe provare a) scrivere sul disco, quindi prova a utilizzare un filesystem di root creato per essere decompresso nella RAM. L'idea qui è che hai un filesystem root compresso all'avvio che viene decompresso nella RAM. Tutte le modifiche si verificano sul disco RAM, quindi non c'è effettivamente nessuna scrittura sulla scheda SD, solo lettura all'avvio. questo dovrebbe ridurre le letture/scritture sul tuo disco, preservandone la vita. Questo è simile a quello che si fa quando si avvia Linux da un CD, ed è una delle prime cose che accade quando Linux si avvia.