Perché la prestazione di scrittura casuale della scheda SD per dimensioni record 8-128 kB scende al di sotto delle prestazioni di dimensioni record 4 kB?


15

Quando controllo le prestazioni delle schede SD per la scrittura casuale, vedo che le prestazioni sono piuttosto pessime per le dimensioni del record di 4 kB (questo non è sorprendente) ma poi per diverse schede scende anche per dimensioni di record più grandi prima di aumentare. Ho misurato le prestazioni di scrittura casuali con iozone v3.430 e testato diverse schede flash di diversi produttori. Questo è il comando iozone, che ho usato per misurare con una dimensione del file di 50 MB:

iozone -RaeI -i 0 -i 1 -i 2 -y 4k -q 1M -s 50m -o -f /tmp/testfile

Questi sono i risultati con dimensioni del file 50 MB:

Riduzione delle prestazioni delle schede SD per la scrittura casuale quando testato con iozone e dimensioni del file di 50 MB

Domanda: Qual è il motivo per cui le prestazioni di scrittura casuali con una dimensione del record di 8, 16, 32, 64 e 128 kB sono più lente rispetto alla dimensione del record di 4 kB?

Peter Brittain ha suggerito di provare con file di dimensioni maggiori, quindi l'ho provato anche con file di dimensioni pari a 500 MB. Questi sono i risultati:

Riduzione delle prestazioni delle schede SD per la scrittura casuale quando testato con iozone e dimensioni del file di 500 MB

Le prestazioni complessive sono peggiorate ma il fenomeno si verifica ancora.

Le partizioni sono allineate ai limiti di 4 MB. Il file system è ext4 con una dimensione di blocco di 4 kB. La partizione utilizzata per l'avvio dei test è mmcblk0p2.

$ lsblk 
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
loop0         7:0    0 953.7M  0 loop /mnt/sdb1
mmcblk0     179:0    0  14.9G  0 disk 
├─mmcblk0p1 179:1    0    56M  0 part /boot
├─mmcblk0p2 179:2    0   7.8G  0 part /
└─mmcblk0p3 179:3    0     7G  0 part /mnt/mmcblk0p3

$ cat /etc/fstab | grep mmcblk0p2
/dev/mmcblk0p2  /               ext4    defaults,noatime  0       1

$ sudo fdisk -l /dev/mmcblk0

Disk /dev/mmcblk0: 15.9 GB, 15931539456 bytes
4 heads, 16 sectors/track, 486192 cylinders, total 31116288 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000981cb

Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1            8192      122879       57344    c  W95 FAT32 (LBA)
/dev/mmcblk0p2          122880    16506879     8192000   83  Linux
/dev/mmcblk0p3        16506880    31115263     7304192   83  Linux

$ mount | grep ext4 | grep root
/dev/root on / type ext4 (rw,noatime,data=ordered)

# tune2fs -l /dev/mmcblk0p2 | grep Block
Block count:              2048000
Block size:               4096
Blocks per group:         32768

Aggiornamento 1: è chiaro che le prestazioni per la scrittura casuale, specialmente per dischi di piccole dimensioni, sono significativamente inferiori rispetto alla scrittura sequenziale. Le celle di memoria della memoria flash NAND sono raggruppate in pagine e sono chiamate blocchi di cancellazione. Le dimensioni tipiche delle pagine sono 4, 8 o 16 kB. Sebbene sia possibile per il controller scrivere singole pagine, i dati non possono essere sovrascritti senza prima essere cancellati e un blocco di cancellazione è l'unità più piccola che può essere cancellata da una memoria flash NAND. La dimensione del blocco di cancellazione è in genere compresa tra 128 kB e 2 MB. Nelle moderne schede SD, un numero ridotto di blocchi di cancellazione viene combinato in unità più grandi di uguale dimensione che vengono chiamate gruppi di allocazione o unità o segmenti di allocazione. La dimensione normale del segmento è di 4 MB.Ogni operazione di scrittura sulla memoria comporta un'operazione di lettura-modifica-scrittura per un intero segmento. Ad esempio, su una scheda SD con dimensioni del segmento di 4 MB, la scrittura di 4 kB di dati in posizioni casuali determina un fattore di amplificazione della scrittura di 1024. I controller delle schede SD implementano un livello di traduzione. Per qualsiasi operazione I / O, il controller esegue una traduzione dall'indirizzo virtuale a quello fisico. Se i dati all'interno di un segmento devono essere sovrascritti, il livello di traduzione rimappa l'indirizzo virtuale del segmento su un altro indirizzo fisico cancellato. Il vecchio segmento fisico è contrassegnato come sporco e messo in coda per una cancellazione. Successivamente, quando viene cancellato, può essere riutilizzato. I controller delle schede SD di solito memorizzano nella cache un singolo o più segmenti per aumentare le prestazioni delle operazioni di scrittura casuali.Se le schede SD memorizzano un file system radice, è utile se il controller della scheda è in grado di memorizzare nella cache i segmenti in cui si svolgono le operazioni di scrittura, i segmenti, che memorizzano i metadati per il file system e (se disponibile) il giornale del file system. Di conseguenza, le prestazioni di scrittura casuali di una scheda SD dipendono dalla dimensione del blocco di cancellazione, dalla dimensione del segmento e dal numero di segmenti, la cache del controller. Ma tutto ciò non spiega perché le prestazioni di scrittura casuali con una dimensione record di 8, 16, 32, 64 e 128 kB siano più lente come con una dimensione record di 4 kB.

Aggiornamento 2 (risposta a myaut): lo screenshot della tabella è opera mia. Attualmente, scrivo un articolo / articolo sui cluster di computer a scheda singola perché sono un'opzione interessante per fornire risorse a progetti e ricercatori di studenti. In questo contesto ho anche studiato le prestazioni della CPU, della memoria e dell'interfaccia di rete di un singolo nodo. Ho acquistato tutte le schede SD testate. Su una delle schede che ho installato (copiato tramite dd) Raspian Wheezy (versione 2014-06-20). Dopo aver configurato le impostazioni di rete e installato alcuni pacchetti aggiuntivi (ad es. Iozone), ho copiato l'intera scheda SD su tutte le altre schede SD.

Aggiornamento 3 (risposta a Gabriel Southern): i risultati provengono da singole corse. La procedura era:

  1. Inserisci la scheda in Raspberry Pi Modello B
  2. Avvia il sistema
  3. Accedi tramite SSH
  4. Avviare il test dello iozone
  5. Arresta il sistema e prova con un'altra scheda SD

Alcune delle carte che ho provato più volte per ricontrollare. C'erano solo poche variazioni. Il fenomeno si verifica sempre, tranne per le due schede Samsung e una scheda Verbatim.

Aggiornamento 4: Al momento provo a trovare un contatto con un'azienda che produce i flash control NAND (Samsung, SanDisk, Toshiba ...) per chiedere una risposta definitiva. SanDisk ha un forum. Ho chiesto lì una spiegazione. Ho anche inviato una richiesta al dipartimento di supporto tecnico di Kingston.

Aggiornamento 5: la dimensione del blocco di cancellazione e la dimensione dell'unità (segmento) di allocazione non sono responsabili del fenomeno. Ho testato la dimensione del blocco di cancellazione di tutte le schede SD con il pritcsd.py pugno utensile nel lettore di schede interno di un notebook ThinkPad X240 e infine con un lampone Pi Modello B. Per tutte le schede l'uscita è: Erase block size of mmcblk0 is 65536 bytes. Anche la dimensione del segmento è uguale per tutte le schede SD testate. Sono 4 MB. Questa informazione può essere trovata nel file /sys/class/mmc_host/mmc0/mmc0*/preferred_erase_size . È abbastanza straordinario secondo me che tutte queste carte hanno le stesse dimensioni del blocco di cancellazione e dimensioni del segmento. Nel frattempo ho raccolto gli ID prodotto / i numeri degli articoli dagli imballaggi delle carte testate. Eccoli.

ID prodotto / numeri articolo dagli imballaggi delle carte testate

Aggiornamento 6: il supporto tecnico di Kingston mi ha scritto che i controller delle schede Kingston testate (e molto probabilmente delle altre carte) sono ottimizzati per file di dimensioni 4 kB. L'esatta implementazione del controller è riservata. La risposta di Kingston è la migliore che ho avuto. SanDisk non ha mai risposto alla mia richiesta di supporto e non sono riuscito a trovare un contatto da Sony, Samsung o Verbatim


1
Questa è una domanda interessante I risultati che hai segnalato sono medi su più corse o solo da una singola corsa? Sarei curioso di sapere quanta variazione ci sia nei risultati.

1
Come risultato della rimappatura logica e del livellamento dell'usura, questa affermazione nella domanda "Ad esempio su una scheda SD con dimensioni del segmento di 4 MB, la scrittura di 4 kB di dati in posizioni casuali provoca un fattore di amplificazione della scrittura di 1024". è falso.
Ben Voigt,

1
Nella mia esperienza di test delle prestazioni, hai raggiunto tutti i tipi di ottimizzazioni e cache a test su scala ridotta. In particolare, potrei credere che i produttori con flash più lento avrebbero bisogno di queste ottimizzazioni per gestire gli aggiornamenti del file system in modo efficiente, ma non posso provarlo a causa della mancanza di documentazione pubblica per tutti i controller. Detto questo, noto che stai usando solo un file da 50 MB. Hai provato file molto più grandi (secondo le "regole di esecuzione" in iozone.org/docs/IOzone_msword_98.pdf ) per provare a contrastare questo?

1
Partendo dal presupposto che non trovi alcuna differenza, ho cercato altri dati in merito. Sembra che la Linaro abbia fatto ricerche simili . In particolare, la cache SLC extra large può spiegare i tuoi risultati molto veloci. E le ottimizzazioni di FAT32 sarebbero mirate specificamente alle piccole scritture.

1
Sì, ho già riscontrato quel problema nella pagina ... Penso che potresti mancare qualcosa con FAT32, tuttavia: le carte sono ottimizzate "per i modelli di accesso osservati su FAT32" e non solo per FAT32. Un tipico modello di accesso su FAT sarà la scrittura di un nuovo file, che richiede lo streaming dei dati del file più un aggiornamento FAT. L'aggiornamento FAT di solito comporta un numero limitato di blocchi. Se stavo scrivendo un FTL, quindi pianificherei di ottimizzare eventuali scritture inferiori alle dimensioni della mia pagina per aiutare le prestazioni FAT.

Risposte:


4

Struttura delle celle delle schede SD:

Nell'elettronica a stato solido, una cella è un elemento di memoria in grado di memorizzare uno o più bit di informazioni, il numero di bit per cella dipende dalla tecnologia utilizzata. (SLC / MLC / TLC)

I produttori utilizzano diverse tecnologie nella memoria flash per gestirne la struttura, la struttura più utilizzata sono TLC e MLC a causa dei costi più economici relativi a tale tecnologia, in particolare TLC.

Queste informazioni tecniche sono difficili da ottenere per le schede SD e le chiavette USB, lo hanno deciso i produttori, per quanto riguarda altre tecnologie come il flash, come SSD dove queste informazioni sono quasi sempre fornite.

Ciò ha un impatto diretto sulla durata dell'hardware ma anche sulla velocità.

SLC, cella a livello singolo (1 bit)

Generally 100000 write erase cycles
Erase time: 1-2.5ms

MLC, cella multilivello (2 o più bit)

Anywhere from 3000 to 15000 write erase cycles
Erase time: 2.5-3.5ms

TLC, cella a tre livelli (3 bit)

Anywhere from 1000 to 5000 write/erase cycles
Erase time: 4-5ms

Nota :

Poiché le celle potrebbero contenere 1, 2 o 3 bit, in alcuni casi il chip del controller della scheda SD dovrà eseguire più cicli di accesso a seconda delle dimensioni del record e della capacità della cella.

Le tue schede Samsung stanno probabilmente utilizzando una tecnologia SLC o hanno un potente chip controller.

Nota 2 :

Ho provato alcuni test come te con partizioni ext4 blocchi di dimensioni 4 kb e 1 kb ma senza grandi differenze


Le schede Samsung e Verbatim sono prodotti di consumo e negli ultimi anni la memoria SLC non era comune in tali dispositivi. Le schede Samsung sono MB-MP16D e MB-MS16D e la scheda testuale è il numero dell'articolo 44007 .
Neverland,

Forse sono disponibili le specifiche di alcuni controller. Posso aprire le schede SD e controllare quali controller contengono queste schede, ma non riesco ad aprire le schede microSD. C'è qualche possibilità di leggere l'ID / numero del prodotto dei controller delle schede SD tramite software?
Neverland,
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.