Non ho l'abitudine di scollegare il pi nel senso di evitare di spegnerli correttamente tranne quando ho perso la rete su un pi senza testa, nel qual caso di solito sono troppo pigro per collegare una tastiera, ecc.
Generalmente controllo sempre per assicurarmi che la luce verde ACT non sia accesa in quel punto; per i modelli recenti (o firmware?) questo sarà spento quando non si accede alla scheda SD. Questo è ciò di cui vuoi essere sicuro. A meno che non ci si scriva costantemente, questo dovrebbe essere abbastanza semplice; fintanto che c'è una discreta quantità di headroom nella RAM libera (diciamo 50-100 + MB, a seconda del contesto), allora le cose che sono inclini a essere riutilizzate frequentemente ma non sono effettivamente caricate da un processo in un dato momento sarà memorizzato nella cache nella memoria libera e ricaricato da lì dal sistema operativo, non dal vero supporto fisico. Ecco come funzionano tutti i moderni sistemi operativi per uso generale.
Se il pi utilizza la scheda SD, ecco il rischio minimo : il filesystem sulla scheda non è sincronizzato con lo stato in memoria. Normalmente, questo non è probabilmente un grosso problema; per cominciare, il journaling del filesystem usato di default sulla maggior parte dei pis potrebbe essere una difesa contro di esso, così come lo è fsck che dovrebbe essere applicato automaticamente all'avvio se il filesystem non è stato smontato in modo pulito. Spiegherò perché dico "potere" e non "è" a breve, perché in questo contesto penso che potrebbe non esserlo .
Per quanto ne so, non ho mai finito con la corruzione del file system o la perdita di dati quando ho rimosso la spina, cosa che avrei potuto fare centinaia o più volte nel corso degli anni. Tuttavia, ancora una volta, non lo faccio abitualmente. Se lo fai più volte al giorno, potresti eventualmente imbatterti in qualsiasi livello di rischio statistico e vi è una cattura potenzialmente cattiva.
Ecco il PROBLEMA:
Di recente mi è venuto in mente che esiste un problema con le schede SD contro cui i meccanismi del sistema operativo / file system potrebbero essere impotenti e che potrebbe spiegare il motivo per cui alcune persone sembrano avere problemi persistenti con la corruzione di fs, in particolare quelli che iniziano a strappare il cavo indipendentemente dal sistema stato - ad esempio, recentemente qualcuno qui ha affermato di eseguire moduli di calcolo in cui la corruzione ha lasciato i sistemi non avviabili in ~ 1/40 interruzioni di corrente.
In termini astratti, senza tenere conto della natura delle schede SD , ciò non dovrebbe accadere anche se il sistema è occupato, perché ciò che è più probabile che finisca per essere danneggiato è materiale non critico che viene scritto, non alcun software di sistema efficace sola lettura e viene modificato solo durante gli aggiornamenti.
Potrebbe accadere se i bit vengono manipolati, e quindi le meta informazioni del filesystem che memorizzano dove sono presenti vari bit sono danneggiate. Ancora una volta, tuttavia, journalling e fsck dovrebbero essere in grado di gestirlo, il che richiede l'avvio del kernel, ma il kernel su pi è su una partizione di avvio separata che potrebbe anche essere smontata durante l'uso (tranne che durante l'aggiornamento) perché nessuno di questi viene utilizzato dopo l'avvio del sistema. Significa che le informazioni sulla partizione dovrebbero essere, in effetti, incorruttibili, anche quando sono montate.
Ma...
Le schede SD sono una scatola nera per il sistema operativo. Non c'è via d'uscita. Mentre ci sono driver specifici per controller di schede SD che fanno parte dell'hardware del computer (sul pi, questo fa parte del SoC) non esiste un driver per diversi modelli e marche di schede specifici.
Eppure, hanno tutti dei microcontrollori al loro interno che possono operare in modi molto diversi. 1. Questo è ciò che rende la carta una scatola nera; interagisce con il sistema operativo tramite un protocollo SD standardizzato, e questo è l'ultimo punto di controllo del sistema operativo.
Una delle cose che fanno le schede SD e altri supporti a stato solido che è diversa dai tradizionali dischi rotanti è l'uso dell'indirizzamento virtuale opaco; non memorizzano fisicamente le informazioni nelle sequenze percepite dal sistema operativo. Questa è principalmente una buona cosa, altrimenti potremmo davvero aver bisogno di driver diversi per le diverse marche di carte, ecc., E permette alle carte di (opacamente) implementare il livellamento dell'usura , che prolunga significativamente la loro durata.
Un'altra cosa su cui si basano sono i "blocchi di cancellazione" relativamente grandi; quando i dati in un blocco devono essere modificati, l' intero blocco viene cancellato e riscritto. Anche i filesystem fanno questo genere di cose come una cosa ovvia, ma si noti che è a livello di software di sistema, e i problemi che ne derivano sono esattamente i tipi di problemi che si verificano durante il viaggio e la gestione fsck.
Il punto cruciale del problema più insormontabile è che i filesystem in scala lo fanno su di solito è molto più piccolo di quanto lo facciano le schede SD in scala. Se così non fosse, si finirebbe per sprecare una buona quantità di spazio di archiviazione, perché un blocco del filesystem può contenere solo dati da un file. Se il blocco è 2 MB e ci sono solo pochi kB di dati, il resto è sprecato. Quindi i blocchi di filesystem tendono a variare da 1/2 KiB a 4 KiB.
È abbastanza ovvio che le schede SD non lo fanno e, in effetti, non potrebbero farlo, poiché il controller in una scheda SD non è a conoscenza di limiti come "file", "filesystem" o persino "partizione del dispositivo". Si occupa solo dei blocchi di dati desiderati dal sistema operativo, tramite uno strato opaco all'interno di una scatola nera in cui tutto potrebbe accadere a livello fisico.
Uno dei motivi per cui è ovvio (a parte le carte premesse "in primo luogo non potevano farlo") è che quei blocchi sono spesso abbastanza grandi, eppure le carte sembrano fare un lavoro decente nell'utilizzare tutto lo spazio. Un blocco di cancellazione può avere dimensioni di diversi megabyte . Inoltre, i dettagli sono proprietari. Mentre potrebbero esserci dei meccanismi attraverso i quali il sistema operativo può richiedere la dimensione del blocco di cancellazione dalla scheda, la scheda non deve fornire questo, può mentire al riguardo, e sarebbe assurdo se il sistema operativo tentasse di sfruttarlo.
Ne consegue che dal momento che:
Il controller della scheda SD non ha idea di quali dati "giustamente" appartengano dove, nel senso di filesystem e paritizioni coerenti, e,
La scheda SD è una scatola nera in cui il sistema operativo non può davvero vedere,
Quindi, ciò che si trova in un determinato blocco di cancellazione da 1 MB, in cui una scheda contiene diverse partizioni che utilizzano 4 KiB o blocchi di filesystem più piccoli, è destinato ad essere arbitrario una volta che la scheda è stata utilizzata abbastanza (e possibilmente anche se non è stata usata molto in tutti). Ciò è probabilmente vero anche se si tenta di forzare il sistema operativo a utilizzare blocchi di dimensioni maggiori / corrispondenti; finiranno per disallinearsi.
Così:
Se si interrompe l'alimentazione mentre la scheda SD è nel mezzo dell'alterazione di un blocco, ciò potrebbe comportare la perdita di un volume abbastanza grande di dati arbitrari che potrebbero essere qualsiasi cosa dalla scheda. Potrebbe essere un'informazione contrassegnata come "sola lettura". Potrebbe essere l'informazione da una partizione che non è nemmeno montata e, ovviamente, dalla partizione di avvio per lo più inutilizzata.
Se ciò accade e la carta non ha un qualche tipo di sistema di protezione proprio (che alcuni potrebbero avere, ma sono sicuro che la maggior parte non lo fa), allora potresti guardare una situazione FUBAR. Il journaling non proteggerà dalla corruzione casuale di dimensioni MB che non riconosce nemmeno i confini della partizione. O fsck.
Oppure, dal momento che l'hardware della scheda è generalmente proprietario, potrebbe nient'altro che software prodotto dal produttore della scheda - presumendo che sia plausibile. Non ne ho mai sentito parlare. Ciò renderebbe le carte più complicate, più costose e più una seccatura da usare. Quale non è l'obiettivo.
Detto in altro modo, le schede SD non devono essere utilizzate in modo affidabile in questo modo . Sono economici e molto utili, ma questo è il risultato di un compromesso nel protocollo: in generale, non vi è alcuna garanzia di integrità dei dati per qualsiasi cosa sulla carta se si uccide arbitrariamente il potere su di essa.
Cosa può andare storto semplicemente scollegando il Pi? Devo iniziare semplicemente a scollegare? Nota: in questo caso non sono troppo preoccupato per la perdita di dati.
Non danneggerà fisicamente il pi, no, solo attenzione che la "perdita di dati" potrebbe estendersi alla "carta inutile" che deve essere completamente riformattata. Tuttavia, direi che se lo fai con la luce verde ACT spenta sono molto basse.
- Ciò può essere significativo se si considera il motivo per cui alcune marche / modelli specifici di carte chiaramente peggiori di altri per alcune persone. Sfortunatamente, mentre due schede identificate in modo identico possono essere identiche in termini di caratteristiche dichiarate (dimensioni, velocità, ecc.), I produttori non sono tenuti a renderle identiche al 100% in termini di parti costitutive.