File system della scheda SD a prova di corruzione per Linux incorporato?

Recentemente abbiamo avuto una situazione piuttosto spiacevole con il nostro cliente: il "kiosk" basato su Raspberry Pi utilizzato per visualizzare i dati di telerilevamento (niente di più sofisticato di un browser in modalità kiosk che mostra una pagina Web autoaggiornamento dal server di raccolta dati) non è riuscito ad avviarsi a causa di corruzione del filesystem. Ext4, Manuale richiesto, il sistema farà parte dell'importante presentazione di domani, servizio richiesto immediatamente. Ovviamente non possiamo richiedere al cliente di spegnere bene il sistema quando lo si spegne per la notte; il sistema deve semplicemente resistere a tali maltrattamenti.

Vorrei evitare tali situazioni in futuro e mi piacerebbe spostare il sistema operativo in un filesystem che lo impedisse. C'è un sacco di filesystem destinati ai dispositivi MTD, dove farli funzionare su scheda SD (un dispositivo a blocchi standard) richiede un serio salto del cerchio. Esistono anche altri filesystem (journaling ecc.) Che vantano una buona resistenza alla corruzione. Ho ancora bisogno di vedere qualche ragionevole confronto tra i loro pro e contro.

Quale filesystem disponibile in Linux fornirebbe la migliore resistenza contro la corruzione in caso di interruzioni di corrente impreviste e non richiedere di saltare attraverso cerchi impossibili come yaffs2 per installare su SD.

Il bilanciamento dell'usura è un vantaggio, ma non un requisito: le schede SD di solito hanno i loro meccanismi, anche se non perfetti, anche se il sistema dovrebbe essere "delicato per il flash" (sistemi come NTFS possono uccidere una scheda SD entro un mese).

La migliore resistenza contro la corruzione su una singola scheda SD sarebbe offerta da BTRFS in modalità RAID1 con scrub automatico eseguito ogni periodo di tempo predefinito.

I benefici:

1. mantenendo la capacità di eseguire RW sul filesystem
2. filesystem moderno e completo con opzioni molto utili per un RPi, come compressione trasparente e istantanee
3. progettato pensando alla memoria flash (tra le altre cose)

Ecco come farlo:

Eseguo il mio RaspberryPi su ArchARM linux e la mia scheda è nel lettore SD, quindi modifichi tali istruzioni di conseguenza per altre distro 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 ottenere btrfs in RAID1, crei il filesystem in questo modo:

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

Quindi il sistema rsync -aAXvè stato precedentemente eseguito il backup.

Per farlo avviare da BTRFS in raid1, è necessario modificare initramfs . Pertanto, è necessario eseguire le operazioni seguenti mentre il sistema è ancora in esecuzione sul vecchio file system.

Raspberry normalmente non utilizza mkinitcpio, quindi è necessario installarlo. Quindi, è necessario 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, è necessario 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 avviato con successo nel tuo sistema RAID1 di btrfs, l'unica cosa rimasta è impostare uno scrub periodico (ogni 3-7 giorni) o con systemd timer (preferito) o cron (dcron) in questo modo:

btrfs scrub start /

Funzionerà sul tuo filesystem confrontando i checksum di tutti i file e correggendoli (sostituendoli con la copia corretta) se trova corruzione.

La combinazione di BTRFS RAID1, single medium e Raspberry Pi rende questa roba piuttosto arcana. Ci è voluto del tempo e del lavoro per mettere insieme tutti i pezzi, ma eccolo qui.

Ben l'archiviazione flash è più desiderabile dell'archiviazione magnetica, per diversi motivi, ma per questa applicazione dirò principalmente perché non ci sono parti in movimento. Detto questo, non credo che esista un filesystem "a prova di corruzione", ma ci sono alcuni filesystem robusti (ext4 essendo uno) là fuori, così come alcune tattiche per aiutare a mitigare la corruzione.

Disco RAM

Se l'immagine dell'RPi non deve cambiare e sembra che non lo sia, se nulla tenterà (o dovrebbe tentare di) scrivere sul disco, prova a utilizzare un filesystem di root creato per essere decompresso nella RAM . L'idea qui è che hai un filesystem di root compresso all'avvio che viene decompresso nella RAM. Tutte le modifiche si verificano sul disco RAM, quindi la scrittura sulla scheda SD è pari a zero, la sola lettura all'avvio. questo dovrebbe ridurre le letture / scritture sul tuo disco, preservandone la vita. Questo è simile a quello che viene fatto quando si avvia Linux da un CD ed è una delle prime cose che si verificano all'avvio di Linux .

Vorrei andare in un altro modo e userei solo un filesystem di sola lettura. Non riesco mai a ottenere il mio raspberry pi abbastanza stabile quando utilizzo un filesystem root di lettura-scrittura sulla sdcard. Puoi semplicemente avviare il tuo root tramite kernel cmdline (ro) o usare un initramfs con piggyback incluso il tuo sistema completo.

Entrambi sono possibili da creare con il mio sistema di compilazione casalingo OpenADK. ( http://www.openadk.org )

Bene, il problema che stai riscontrando qui è che l'uso di un filesystem "moderno" come ext * rischia di logorare la tua scheda SD; dalla mia esperienza che accade tra un anno o l'anno successivo se prendi la fascia più alta.

Il problema è che i moderni filesystem spostano sempre i blocchi per prevenire la frammentazione dei dati. Il che è positivo per i dischi rotanti, in cui si desidera che tutti i dati vengano raccolti durante il caricamento nella cache. Il rovescio della medaglia è che sta facendo più scritture che non possono essere memorizzate nella cache poiché il riordino viene gestito quando non si verificano molti I / O.

Succede anche quando gestisci molte registrazioni, cosa che potresti voler fare quando esegui il debug del tuo dispositivo incorporato. Le scritture di registrazione sono il peggior tipo di scritture, perché sono molte le piccole scritture che si verificano regolarmente, il che genera molta frammentazione.

Come dici tu, anche il tuo sistema sta gestendo i dati del sensore, è molto probabile che li memorizzi sul flash man mano che arrivano. E sono cattivi come i dati di registro.

Ho riscontrato lo stesso problema in cui ti imbatti, ed ecco le mie conclusioni. Ho cercato di cercare schede SD che sarebbero state vendute come "più robuste", cioè in grado di gestire più scritture rispetto alle altre, ma non ho trovato alcun benchmark sul mercato che si concentri su questo, a differenza dei benchmark sull'SSD. Poiché tutti si concentrano solo sulla velocità, è impossibile conoscere il numero di scritture per blocco di memoria e la tecnologia utilizzata nella SDCard.

Tuttavia, ho notato che i sandischi di tipo "industriale" hanno una durata più lunga di quelli senza nome. Il che non è sorprendente, quando paghi di più, ottieni di più.

Ma alla fine, con la registrazione intensiva abilitata, non ho trovato alcuna scheda SD con una durata superiore a un paio d'anni, un anno è il luogo in cui si verifica la maggior parte della morte.

Le soluzioni che mi sono venute in mente sono le soluzioni di @ BigHomie e @wbx: utilizzare un filesystem extX di sola lettura (poiché non è più necessario il journaling, è anche possibile eseguire il fallback al buon vecchio ext2). E se si desidera mantenere i registri all'interno della sessione o scrivere file temporanei, è sempre possibile utilizzare un RAMDISK.

Esistono solo tutorial e script che aiutano a popolare il ramdisk con i dati all'interno delle parti di sola lettura in modo da poterli modificare per la sessione.

NB: la mia esperienza è stata quella di utilizzare Angstrom Linux su un Beaglebone, tra una serie di prove di 20 dispositivi a sensore. La registrazione di quel sistema era molto dettagliata, usando il sistema journal di systemd.

Linux offre molti filesystem. ext4 è quello in cui ho più fiducia. In caso di dubbio, ext4 dovrebbe essere usato per qualsiasi partizione che verrà montata in lettura-scrittura.

Il filesystem ext2 è molto più fragile. È un file system perfettamente valido per i sistemi in grado di montarlo in sola lettura o di smontarlo correttamente. Ma la corruzione è estremamente probabile con un'interruzione dell'alimentazione su ext2 .

L'altra opzione potrebbe essere prendere in considerazione jfs anche se il file system jfs non è affidabile in alcune versioni di Linux. La corruzione è meno probabile con jfs che con ext4 . Jfs ha anche un tempo di montaggio rapido e tempo di controllo del file system.