Scelta del filesystem per GNU / Linux su una scheda SD


31

Ho un sistema basato su ARM incorporato in esecuzione su una scheda SD. Attualmente Debian GNU / Linux usa ext3 come filesystem. Mentre sto per reinstallare il sistema, ho iniziato a chiedermi come passare a un filesystem più flash-friendly. Ho sentito parlare di JFFS2, YAFFS2 e LogFS e sembrano tutti adatti al lavoro. Quale consiglieresti? Inoltre, ho sentito che ci sono stati molti miglioramenti ext4 per adattarsi meglio ai dischi SSD; Devo interpretare che come eseguire ext4 dovrebbe andare bene? Cosa devo pensare in particolare in quel caso?

Immagino che l'uso del sistema sia importante. Ma per motivi di generalità, immagina che farà cose desktop standard (anche se è in effetti un piccolo sistema basato su ARM).

Grazie per eventuali risposte

Modifica: Wikipedia mi dice (in una dichiarazione "citazione necessaria") che le schede di memoria flash rimovibili e le unità flash USB hanno controller integrati per eseguire il livellamento dell'usura e la correzione degli errori, quindi l'uso di un file system flash specifico non aggiunge alcun vantaggio . Quindi, mi sto inclinando a rimanere con un filesystem ext.

Risposte:


18

Ottimo articolo sui filesystem flash .

La domanda importante quando si parla di filesystem flash è la seguente: che cos'è il livellamento dell'usura? Articolo di Wikipedia . Fondamentalmente, sui dischi flash è possibile scrivere un numero limitato di volte fino a quando il blocco non va male. Dopodiché, il filesystem (se non esiste una gestione integrata del livellamento dell'usura sull'hardware, come nel caso degli SSD di solito c'è) deve contrassegnare quel blocco come non valido ed evitare di usarlo più.

I filesystem tipici (ad esempio ReiserFS, NTFS, ext3 e così via) sono progettati per dischi rigidi, che non presentano tali limiti.

JFFS2

Include compressione ed elegante protezione antiusura.

YAFFS2

  • Un'unica cosa che fa la differenza: brevi tempi di montaggio, dopo umount riuscito.
  • Proprietà write once once: una volta che i dati vengono scritti su un blocco, non è necessario riscriverli. Questo è importante, in quanto riduce l'usura.

logfs

  • Non molto maturo, ma già incluso nell'albero del kernel Linux.
  • Supporta filesystem più grandi di JFFS2 / YAFFS2 senza problemi.

ubifs

  • Più maturo di LogFS
  • Scrivi supporto per la memorizzazione nella cache
  • Sulla scalabilità: articolo . Su dischi di grandi dimensioni, prestazioni migliori rispetto a JFFS2

ext4

Se nessun driver o scheda (ad esempio, le unità SSD hanno un livellamento interno dell'usura, almeno di solito) gestiscono il livellamento dell'usura, ext4 non è la migliore idea, in quanto non è inteso per l'uso del flash raw.

Qual'è il migliore?

Naturalmente, dipende dall'uso e dal supporto. Da quello che ho letto su Internet, consiglierei UBIFS. Buon supporto per filesystem di grandi dimensioni, fase di sviluppo matura, prestazioni adeguate e nessun grande svantaggio.


6
Grazie, questo è molto istruttivo! Tuttavia, la "grande nota rossa" del sito Web UBIFS dice: "Una cosa che le persone devono capire quando hanno a che fare con UBIFS è che UBIFS è molto diverso da qualsiasi file system tradizionale - non funziona su dispositivi a blocchi (come i dischi rigidi , Schede MMC / SD, unità flash USB, SSD, ecc.) UBIFS è stato progettato per funzionare su flash raw, che non ha nulla a che fare con i dispositivi a blocchi. Ecco perché UBIFS non funziona su schede MMC e simili - loro sembrano dispositivi a blocchi all'esterno perché implementano il supporto FTL (Flash Translation Layer) nell'hardware. "
gspr

3
Bella risposta, in più c'è F2FS di Samsung, anche un sistema molto promettente, anche se abbastanza nuovo.
lzap,

16
@gspr è corretto: SD ha un livello di traduzione flash e JFFS2, YAFFS2, LOGFS e UBIFS sono tutti progettati per flash non gestiti . Le opzioni per SD sono file system tradizionali per dispositivi a blocchi, come ext2 / ext3 / ext4.
Robert Calhoun,

@Olli NILFS2 è una buona scelta per un'unità SSD?
SebMa,

12

Stavo affrontando lo stesso problema e ho fatto anche qualche ricerca. Alla fine ho deciso di andare con ext2.

Sembra che alcune schede SDHC implementino il proprio livellamento dell'usura a livello hardware. Se riesci a procurarti le schede SDHC che hanno il buit-in di livellamento dell'usura.

I filesystem che forniscono il livellamento dell'usura possono interferire con il livellamento dell'usura a livello Flash, quindi può effettivamente essere un male per il flash utilizzarli (l'articolo IBM citato sopra parla di come lo fa JFFS, quindi è chiaro che non funzionerà con livello di illuminazione WL). Ho deciso di non aver bisogno del journaling di ext3 poiché non sto memorizzando dati critici su di esso e di solito eseguo comunque il backup regolarmente (cron).

Ho anche montato / tmp e / var come tmpfs per velocizzare le cose. Se hai abbastanza RAM, dovresti farlo (ma assicurati di ruotare o eliminare i log regolarmente)

SUGGERIMENTO: monta le tue schede SD ext con l'opzione "noatime"


Ho avuto problemi con le vecchie schede SD e ext2 (danneggiamento dei dati) che sono scomparsi quando si è passati a XFS.
Alexander

1

Non so se questo si adatta al profilo del tuo sistema, ma per quanto riguarda l'utilizzo di un filesystem di sola lettura più una partizione di lettura / scrittura (o una chiavetta USB che può essere sostituita facilmente)? In questo modo avrai un disco veloce per il tuo sistema operativo e potrai sostituire facilmente il tuo archivio rw quando si esaurisce.

E poi ci sono unionfs. Come ho capito, "impila" diversi filesystem (cioè un ro fs sopra un rw fs). Se c'è un accesso in lettura, unionfs cerca attraverso lo stack fino a quando non raggiunge l'FS contenente il file che cerchiamo. Quando si scrive unionfs cerca il primo FS scrivibile nello stack e lo utilizza.

Ho anche trovato questi articoli che potrebbero essere interessanti: http://www.linux-mag.com/id/7357/ http://www.linux-mag.com/id/7345/

E due articoli con suggerimenti per l'uso degli SSD: http://danweinreb.org/blog/using-solid-state-disks-on-linux http://www.zdnet.com/blog/perlow/geek-sheet-a- tweakers-guida-to-a stato solido SSD drive--e-linux / 9190


1
Nota che non sono io quello che ha votato in negativo questa risposta. Contiene informazioni utili in generale, ma non è correlato a ciò di cui ho bisogno. Grazie comunque :)
gspr

0

Selezionare (e dimensionare) il file system corretto è più importante di ogni altra cosa, non solo per motivi di sicurezza, ma per tonnellate di altri motivi che le persone di solito non riconoscono. Senza un file system tutta l'elaborazione andrebbe a null.

Molto bene la risposta di Olli, e l'OP è molto datato, ma i file system sono la mia causa per cui non potevo stare lontano. superuser.com non è qualcosa che ho visitato prima, non sono un amministratore, ma mi sono registrato e visiterò di più.

Le cose sono cambiate molto dal 2011, ma anche allora ho formattato le schede USB FAT e usato le unità USB per trasportare file da 4Gb +. Il motivo ovviamente era la compatibilità non la sicurezza (così tanto per S in SD, ma uso password sui miei 7z), e non ho mai trasportato nulla di più grande di un CD ISO, erano principalmente per script SQL e differenze orarie giornaliere di già 7-Zip: snapshot di database crittografati compressi quasi alla morte.

In questi giorni porto qualsiasi SD più veloce di chiunque conosca. Ho una chiavetta USB in alcune macchine di produzione presso il mio datore di lavoro per il backup automatico orario, formattato FAT. Ogni giorno li tengo d'occhio e - avete indovinato - li backup religiosamente a mano (sono prodotti ITAR off-line sicuri e sicuri). L'SSD ha livellato un po 'il campo di gioco, ma non mi fido ancora di loro come un normale HD e SD è peggio dell'ottica. In un attimo vanno male e la perdita è totale.

Qualsiasi file system che invita il sistema operativo host a scrivere casualmente su di esso (NTFS, Cestino) è una cattiva notizia per una SD. Inoltre, lo smontaggio aiuta molto, nessun sistema operativo proverà ad accedere allo spazio di archiviazione non montato, quindi qualsiasi file system farà finché la SD include uno script per smontare da sola (uno dei file standard su ogni SD sulla mia).

La lettura di una SD è ancora lenta oggi, quindi consiglierei qualcosa come il dump del disco (dd) di afferrare l'intera immagine durante il mirroring anziché il file per file. dd ti fa anche sapere quando c'è qualcosa che non va, quindi il tuo file manager non diventerà kaboom.

Naturalmente, se il tuo scopo principale è quello di prolungare la vita di alcuni stock di penny, stai andando nel tuo business nel modo sbagliato. Faccio quello che non faccio per prolungare la vita di una SD ma per evitare che vada male quando non guardo, e c'è la differenza.

Evito ext4 o qualsiasi journaling su SD perché non mi interessa quando vanno male a scriverli, ma fa male quando un giorno o due dopo non riesco a leggerli!


2
Ci dispiace ma questo non risponde davvero alla domanda. È un saggio interessante sull'uso di supporti rimovibili ma non sulla scelta del filesystem.
suspectus,

Volevo commentare ma non potevo. Il post è un po 'prolisso, ciò che ho raccomandato non era né l'OP considerato, ma ho raccomandato FAT. Avrei dovuto comporre con maggiore attenzione e chiarezza di sicuro.
arch-abit,

Perché lo è Any file system which invites the host OS to write randomly to it (NTFS, Recycle Bin) is bad news for an SD.? Non consiste in dischi rotanti, quindi ovunque tu legga / scrivi non dovrebbe importare, penso. E a proposito, NTFS scrive in modo contiguo, il che porta alla frammentazione. «Archivi casuali di file» riguarda, ad esempio, EXTα.
Hi-Angel,

0

Come risposta alla raccomandazione di usare fat (32?): Ho fatto alcuni test sulle prestazioni e ho scoperto che fat32 ha un tempo molto prevedibile per scrivere un file (2 GB ha bisogno di due volte di 1 GB + offset, 3 GB ha bisogno di tempi dell'albero di 1 GB + offset). Le prestazioni di ext4 sono leggermente migliori di ext3. Sia ext3 che ext4 sono a volte veloci ma a volte hanno bisogno di un po 'di tempo extra per scrivere i file journal su disco (nessun comportamento di tempo di scrittura lineare). Tutti i test sono stati eseguiti con fsync () per essere sicuri che il file sia realmente scritto sul disco. Ho eseguito alcuni test con sync (). Si traducono in prestazioni di scrittura pessime. Quindi sono tornato a fsync (). Ho fatto qualche controllo se fsync () è sufficiente. Pertanto ho alimentato il dispositivo senza l'arresto del sistema o rimosso la scheda SD senza smontare. In nessun caso i file scritti o la struttura della directory sono stati danneggiati.

Saluti, Thomas


1
Il confronto è ingiusto. Hai confrontato FAT senza journaling con journaling EXT3 / 4. Dovresti confrontare FAT vs EXT2. E proprio FYI, il file system che è stato preformattato dal produttore di solito ha le dimensioni / offset dei blocchi più ottimali. Cioè dopo che hai riformattato il file system, c'è la possibilità che IO impieghi più tempo rispetto a quello originale.
Hi-Angel,

0

se si desidera una scheda SD senza perdita di dati, si consiglia di utilizzare BTRFSperché:

BTRFS è un nuovo file system rispetto a EXT originariamente creato da Oracle nel 2007.

Offre nuove funzionalità ai filesystem tradizionali:

  • Clonazione / istantanee
  • Diff (invio / ricezione)
  • Quotat
  • Unione
  • Autoguarigione (con periodi di commit predefiniti a 30 secondi)

per ulteriori spiegazioni e confronti fare riferimento a questo pdf

per nuovi confronti fare riferimento a questo sito

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.