File system Linux più veloce su dischi con ghiaia

Vi è un notevole interesse per le unità a scandole. Questi mettono le tracce di dati così vicine tra loro che non puoi scrivere su una traccia senza ostruire la successiva. Ciò può aumentare la capacità del 20% circa, ma comporta problemi di amplificazione della scrittura. Sono in corso lavori su filesystem ottimizzati per le unità Shingled, ad esempio consultare: https://lwn.net/Articles/591782/

Alcuni dischi shedled come l'archivio Seagate da 8 TB dispongono di un'area cache per scritture casuali, che consente prestazioni decenti su file system generici. Il disco può anche essere abbastanza veloce su alcuni carichi di lavoro comuni, fino a circa 200 MB / sec di scritture. Tuttavia, è prevedibile che se la cache di scrittura casuale trabocca, le prestazioni potrebbero risentirne. Presumibilmente, alcuni filesystem sono in grado di evitare scritture casuali in generale, o modelli di scritture casuali che potrebbero traboccare la cache di scrittura trovata in tali unità.

Un filesystem mainstream nel kernel di Linux è migliore nell'evitare la penalità prestazionale dei dischi shedled rispetto a ext4?

I filesystem strutturati intuitivamente Copy-on-Write e Log potrebbero offrire migliori prestazioni sui dischi shedled riducendo la riduzione delle scritture casuali. I benchmark supportano in qualche modo questo, tuttavia, queste differenze di prestazioni non sono specifiche per i dischi shedled. Si verificano anche su un disco non frullato utilizzato come controllo. Pertanto, il passaggio a un disco shedled potrebbe non avere molta rilevanza nella scelta del filesystem.

Il filesystem nilfs2 ha dato prestazioni abbastanza buone sul disco SMR. Tuttavia, ciò è dovuto al fatto che ho allocato l'intera partizione da 8 TB e il benchmark ha scritto solo ~ 0,5 TB, quindi non è stato necessario eseguire il nilfs cleaner. Quando ho limitato la partizione a 200 GB, i benchmark nilfs non si sono nemmeno completati con successo. Nilfs2 può essere una buona scelta dal punto di vista delle prestazioni se si utilizza davvero il disco "archive" come disco di archivio in cui si conservano tutti i dati e le istantanee scritte sul disco per sempre, poiché quindi nilfs cleaner non deve essere eseguito.

Comprendo che l' ST8000AS0002-1NA17Zunità Seagate da 8 TB utilizzata per il test ha un'area cache di ~ 20 GB . Ho modificato le impostazioni predefinite del file server di filebench in modo che i benchmark impostati fossero ~ 125 GB, più grandi dell'area cache non frazionata:

set $meanfilesize=1310720
set $nfiles=100000
run 36000

Ora per i dati effettivi. Il numero di op misura le prestazioni "complessive" del fileserver mentre ms / op misura la latenza dell'appendice casuale e potrebbe essere usato come una guida approssimativa all'esecuzione di scritture casuali.

$ grep rand *0.out | sed s/.0.out:/\ / |sed 's/ - /-/g' |  column -t
SMR8TB.nilfs   appendfilerand1   292176ops 8ops/s   0.1mb/s   1575.7ms/op    95884us/op-cpu [0ms - 7169ms]
SMR.btrfs      appendfilerand1  214418ops  6ops/s   0.0mb/s  1780.7ms/op  47361us/op-cpu  [0ms-20242ms]
SMR.ext4       appendfilerand1  172668ops  5ops/s   0.0mb/s  1328.6ms/op  25836us/op-cpu  [0ms-31373ms]
SMR.xfs        appendfilerand1  149254ops  4ops/s   0.0mb/s  669.9ms/op   19367us/op-cpu  [0ms-19994ms]
Toshiba.btrfs  appendfilerand1  634755ops  18ops/s  0.1mb/s  652.5ms/op   62758us/op-cpu  [0ms-5219ms]
Toshiba.ext4   appendfilerand1  466044ops  13ops/s  0.1mb/s  270.6ms/op   23689us/op-cpu  [0ms-4239ms]
Toshiba.xfs    appendfilerand1  368670ops  10ops/s  0.1mb/s  195.6ms/op   19084us/op-cpu  [0ms-2994ms]

Poiché Seagate è 5980 giri / min, ci si può aspettare ingenuamente che il Toshiba sia più veloce del 20%. Questi benchmark mostrano che è circa 3 volte (200%) più veloce, quindi questi benchmark stanno colpendo la penalità delle prestazioni shedled. Vediamo che il disco Shingled (SMR) non riesce ancora a eguagliare le prestazioni ext4 con su un disco non triturato (PMR). Le prestazioni migliori sono state con nilfs2 con una partizione da 8 TB (quindi non è stato necessario eseguire il dispositivo di pulizia), ma anche allora è stato significativamente più lento del Toshiba con ext4.

Per rendere più chiari i benchmark sopra, potrebbe essere utile normalizzarli in relazione alle prestazioni di ext4 su ciascun disco:

                ops     randappend
SMR.btrfs:      1.24    0.74
SMR.ext4:       1       1
SMR.xfs:        0.86    1.98
Toshiba.btrfs:  1.36    0.41
Toshiba.ext4:   1       1
Toshiba.xfs:    0.79    1.38

Vediamo che sul disco SMR btrfs ha il maggior vantaggio sulle operazioni complessive che ha su ext4, ma la penalità per gli accidenti casuali non è drammatica come un rapporto. Questo potrebbe indurre uno a passare a btrfs sul disco SMR. D'altra parte, se hai bisogno di aggiunte casuali a bassa latenza, questo benchmark suggerisce che vuoi xfs, specialmente su SMR. Vediamo che mentre SMR / PMR potrebbe influenzare la scelta del filesystem, considerando il carico di lavoro per il quale stai ottimizzando sembra più importante.

Ho anche eseguito un benchmark basato su soffitta. Le durate delle corse della soffitta (sulle partizioni complete del disco SMR da 8 TB) sono state:

ext4:  1 days 1 hours 19 minutes 54.69 seconds
btrfs: 1 days 40 minutes 8.93 seconds
nilfs: 22 hours 12 minutes 26.89 seconds

In ogni caso i repository attico avevano le seguenti statistiche:

                       Original size      Compressed size    Deduplicated size
This archive:                1.00 TB            639.69 GB            515.84 GB
All archives:              901.92 GB            639.69 GB            515.84 GB

L'aggiunta di una seconda copia dello stesso disco da 1 TB in soffitta ha richiesto 4,5 ore su ciascuno di questi tre filesystem. Un dump grezzo di benchmark e smartctlinformazioni è disponibile all'indirizzo: http://pastebin.com/tYK2Uj76 https://github.com/gmatht/joshell/tree/master/benchmarks/SMR

Se rsync da un disco SMR, assicurarsi che il filesystem è montato read-onlyo con noatimel'opzione.

In caso contrario, l'unità SMR dovrà scrivere un timestamp per ogni file letto da rsync, determinando un significativo degrado delle prestazioni (da qui circa 80 mb / s fino a 3-5 mb / s) e usura della testina / rumore del clic.

Se hai già un lavoro rsync in esecuzione con scarse prestazioni, non è necessario interromperlo, puoi rimontare il filesystem di origine facendo

sudo mount -o remount,ro  /path/to/source/fs

L'effetto non si vedrà immediatamente, sii paziente e attendi dai 10 ai 20 minuti, fino a quando l'unità avrà terminato di scrivere tutti i dati ancora nei suoi buffer. Questo consiglio è provato e testato ok.

Questo potrebbe anche applicarsi quando rsyncing ad un'unità SMR, vale a dire se il filesystem tenta di aggiornare il timestamp dopo che il file è stato completamente scritto su disco. Questo carico di lavoro sequenziale di nervosismo e enormi bande di dati vengono continuamente riscritte, contribuendo a guidare l'usura. Quanto segue può aiutare:

sudo mount -t fs_type -o rw,noatime device /path/to/dest/fs

Questo deve essere fatto, prima di eseguire rsync; altri fattori possono rendere insignificante questa opzione, ovvero l'aggiornamento FAT / MFT senza buffer, scritture in parallelo se il filesystem è ottimizzato principalmente per SSD, ecc.

Prova a usare dd bs=32Me quindi ridimensionare il filesystem sulla destinazione SMR, se vuoi comunque eseguire il backup di filesystem completi (non è necessario averlo montato ed eseguire rsync per trasportare tutti i file in questo caso).

L'hardware effettivo in uso era un'unità consumer SMR da 8 tb gestita da Seagate. Il chilometraggio può variare con altri componenti hardware.