Domanda:
Interfaccia scheda MMC / SD: accesso alle informazioni sul livellamento dell'usura? (contatori, ecc.)
darron
2011-12-10 10:28:07 UTC
view on stackexchange narkive permalink

Non credo che ci sia qualcosa nelle specifiche della scheda MMC / SD per il recupero di informazioni sui conteggi di cancellazione su una scheda MMC / SD, vero?

Il mio obiettivo è far sì che il mio sistema integrato evitare di scrivere su metadati come ultimo accesso o tempi di modifica, allocare file di dimensioni moderate riempiti con 0xFF sa necessario e aggiungere record solo all'interno.

Questo per ridurre il rischio di perdita di dati, poiché l'alimentazione può essere persa in qualsiasi momento.

Tuttavia, gli algoritmi di livellamento dell'usura delle schede MMC / SD sono sconosciuti e potrebbero essere implementati molto male. Devo verificare che le carte non tentino di cancellare i blocchi di dati se sto solo scrivendo dati su 0xFFs. Quindi, se ci fosse praticamente qualsiasi tipo di conteggio delle cancellazioni (totale per il disco, per blocco, qualunque cosa) disponibile per la lettura ... sarebbe fantastico.

Non sono del tutto sicuro di dove questo la domanda vive ... ma poiché si tratta di cose a livello di protocollo della scheda SD, ho pensato che forse qui.

MODIFICA

Credo che andrò avanti e complicherò troppo cose. I test del disco hanno dimostrato che almeno le schede SD che ho cancelleranno i blocchi anche se i dati che scrivi non vengono modificati dal contenuto del disco. Memorizzerò fino a 128 KB di dati in una NAND controllabile direttamente (su cui posso controllare un po 'meglio il comportamento di scrittura), quindi scriverò blocchi di 128 KB in un file allineato a 128 KB sulla partizione VFAT. Questo dovrebbe limitare l'esposizione il più possibile ... ma wow quanto sia brutto e complicato.

Nel mio prossimo data logger, sto pensando di scrivere tutto in modo ridondante due volte, su 2 schede di memoria. Prima uno, quindi - dopo che sono sicuro che la prima scrittura è terminata - quindi scrivi gli stessi dati nell'altro. Non importa quando le batterie si guastano, nel peggiore dei casi una scheda sarà danneggiata e tutti i dati (tranne forse l'ultimo blocco) saranno al sicuro sull'altra scheda.
Una risposta:
supercat
2011-12-10 12:21:20 UTC
view on stackexchange narkive permalink

Non so se particolari schede SD espongano informazioni di livellamento dell'usura, ma per la maggior parte suggerirei che il tuo desiderio di evitare di cancellare i blocchi che contengono FF è fuori luogo. Anche se un blocco del disco virtuale contiene solo FF, quasi certamente conterrà altre informazioni di indirizzamento e dati di correzione degli errori che dovranno essere riscritti se vengono apportate modifiche al blocco, indipendentemente dal suo contenuto precedente.

Credo che i produttori di schede SD siano liberi di selezionare i propri algoritmi per decidere quando riscrivere i blocchi a cui non si accede da un po 'e per garantire l'integrità dei dati in caso di interruzione di corrente. Di conseguenza, non conosco alcun metodo particolare per garantire che una scheda SD non venga danneggiata se si interrompe l'alimentazione durante una scrittura.

Ah, ottimo punto. Ho dimenticato i bit ECC. Questo praticamente distrugge l'idea. Hmm ... immagino che questa domanda sia fatta ... andrò a chiedere al consiglio di amministrazione di Linux di file system affidabili in questa situazione.
@darron: È una domanda interessante; L'ho votato positivamente (qualcun altro lo ha svalutato) Dal momento che le schede MMC e CompactFlash mettono uno strato di mappatura dei blocchi virtuale sopra un dispositivo flash grezzo, non credo che possano esporre gli stessi dettagli di livellamento dell'usura come fa qualcosa come SmartMedia. Sebbene gli standard basati sulla virtualizzazione come SD / MMC siano più adattabili alle tecnologie in evoluzione rispetto agli standard "raw bits" come SmartMedia, per alcune applicazioni ci sono sicuramente dei vantaggi nel sapere cosa sta realmente accadendo.
@darron: Non so se hai familiarità con il funzionamento delle moderne unità flash, ma sono generalmente progettate per essere scritte in pagine di 528 byte, pur essendo cancellabili solo in blocchi molto più grandi (penso che 32KB, ma forse 128 KB o anche più grande). Se viene richiesta la scrittura di un settore, la chiavetta troverà una pagina vuota se ce n'è una, vi scriverà il nuovo settore e in qualche modo indicherà che la nuova pagina è quella "reale" per quel settore e quella vecchia è obsoleto. Se il numero di pagine vuote disponibili si avvicina al valore di un blocco (o in diversi altri momenti), ...
@darron: ... il sistema proverà a trovare un blocco che contiene le pagine più obsolete, copia tutte le pagine da quel blocco a pagine vuote, quindi cancella l'intero blocco. Un problema con questo approccio è che un disco che ha poche pagine vuote ma ha ad es. una pagina "obsoleta" per blocco di cancellazione potrebbe riportare di avere molto spazio disponibile, ma la scrittura di ogni pagina richiederà la cancellazione di un blocco e la copia di una pagina di dati nel nuovo blocco. Lento.
Hmm ... sì, se ECC è per blocco di 512 byte, come suggerisce 528, questo potrebbe ancora funzionare ... se scrivo solo con incrementi di 512 byte. Conoscevo le dimensioni del blocco di cancellazione e avevo pianificato di farlo in blocchi da 128 KB. (immaginando che la maggior parte dei blocchi di cancellazione delle carte sarebbe uguale o inferiore a quello)
Ritardare per 512 byte nella mia situazione significherebbe un ritardo massimo di 15-30 secondi. È accettabile. Ho anche determinato un modo per testare il comportamento di cancellazione delle carte senza accesso per cancellare le informazioni del tipo di contatore ... cronometra! Scriverò un'app per scrivere 512 byte alla volta in un file. Uno aggiungerà 0 solo in un file pre-inizializzato a 0xFFs. L'altro scriverà in modi che la forza cancella. Dopo alcuni minuti di esecuzione, dovrebbe mostrare una differenza (significativa) nel tempo impiegato se il metodo di aggiunta non impone la cancellazione. Posso persino rendere questo test parte di una routine di inizializzazione della scheda.
Dubito che qualsiasi controller SD tenterà di sfruttare la possibilità di trasformare un blocco FFFF ... in qualcos'altro senza un ciclo di cancellazione. Sarebbe possibile progettare un controller e un algoritmo EEC in modo tale da chiedere di consentirlo, ma si consideri che scrivendo tutti gli FF nel settore 19543 si crea davvero una pagina che dice "La versione 39191 del settore 19543 contiene FFFFFF ...". La sequenza di bit ECC per quella pagina potrebbe non essere compatibile con "La versione 39191 del settore 19543 contiene 123456 ...".
Hmm. È peggio di quanto pensassi ... nei test direct-to-disk, no-fs-buffer, la scrittura dello stesso identico contenuto su un blocco richiedeva lo stesso tempo della scrittura di blocchi alterati (~ 10 secondi per 1000 record da 64 KB). Potrei anche determinare che il blocco di cancellazione della mia particolare scheda SD è molto probabilmente 64 KB.


ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...