El sistema de archivos Linux más rápido en discos escalonados

Existe un considerable interés en las unidades de tejas. Estos ponen las pistas de datos tan juntas que no puedes escribir en una pista sin golpear la siguiente. Esto puede aumentar la capacidad en un 20% más o menos, pero genera problemas de amplificación de escritura. Se está trabajando en sistemas de archivos optimizados para unidades Shingled, por ejemplo, consulte: https://lwn.net/Articles/591782/

Algunos discos shingled, como el archivo Seagate 8TB, tienen un área de caché para escrituras aleatorias, lo que permite un rendimiento decente en sistemas de archivos genéricos. El disco puede incluso ser bastante rápido en algunas cargas de trabajo comunes, hasta alrededor de 200 MB / seg de escritura. Sin embargo, es de esperar que si la memoria caché de escritura aleatoria se desborda, el rendimiento puede verse afectado. Presumiblemente, algunos sistemas de archivos son mejores para evitar escrituras aleatorias en general, o los patrones de escrituras aleatorias pueden desbordar la caché de escritura encontrada en tales unidades.

¿Es mejor un sistema de archivos convencional en el kernel de Linux para evitar la penalización de rendimiento de los discos escalonados que ext4?

Intuitivamente, los sistemas de archivos estructurados Copiar en escritura y registro pueden proporcionar un mejor rendimiento en discos mezclados al reducir la reducción de escrituras aleatorias. Los puntos de referencia respaldan esto, sin embargo, estas diferencias en el rendimiento no son específicas de los discos en shingled. También se producen en un disco no fragmentado que se usa como control. Por lo tanto, el cambio a un disco shingled podría no tener mucha relevancia para su elección del sistema de archivos.

El sistema de archivos nilfs2 dio un rendimiento bastante bueno en el disco SMR. Sin embargo, esto se debió a que asigné toda la partición de 8TB, y el punto de referencia solo escribió ~ 0.5TB para que el limpiador nilfs no tuviera que ejecutarse. Cuando limité la partición a 200 GB, los puntos de referencia nilfs ni siquiera se completaron con éxito. Nilfs2 puede ser una buena opción en cuanto al rendimiento si realmente usa el disco "archivo" como un disco de archivo donde guarda todos los datos e instantáneas escritos en el disco para siempre, ya que entonces nilfs Cleaner no tiene que ejecutarse.

Entiendo que la ST8000AS0002-1NA17Zunidad Seagate de 8 TB que utilicé para la prueba tiene un área de caché de ~ 20 GB . Cambié la configuración predeterminada del servidor de archivos de Filebench para que el conjunto de puntos de referencia fuera ~ 125 GB, más grande que el área de caché no cifrada:

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

Ahora para los datos reales. El número de operaciones mide el rendimiento "general" del servidor de archivos, mientras que ms / op mide la latencia de la adición aleatoria, y podría usarse como una guía aproximada para el rendimiento de las escrituras aleatorias.

$ 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]

Como Seagate tiene 5980 RPM, uno podría esperar ingenuamente que Toshiba sea un 20% más rápido. Estos puntos de referencia muestran que es aproximadamente 3 veces (200%) más rápido, por lo que estos puntos de referencia están alcanzando la penalización de rendimiento escalonada. Vemos que el disco Shingled (SMR) todavía no puede igualar el rendimiento ext4 con un disco no shingled (PMR). El mejor rendimiento fue con nilfs2 con una partición de 8TB (por lo que el limpiador no necesitaba ejecutarse), pero incluso entonces fue significativamente más lento que el Toshiba con ext4.

Para que los puntos de referencia anteriores sean más claros, podría ayudar a normalizarlos en relación con el rendimiento de ext4 en cada 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

Vemos que en el disco SMR btrfs tiene la mayor ventaja en las operaciones generales que tiene en ext4, pero la penalización en adiciones aleatorias no es tan dramática como una relación. Esto podría llevar a uno a moverse a btrfs en el disco SMR. Por otro lado, si necesita anexos aleatorios de baja latencia, este punto de referencia sugiere que desea xfs, especialmente en SMR. Vemos que si bien SMR / PMR puede influir en su elección del sistema de archivos, considerar la carga de trabajo para la que está optimizando parece más importante.

También ejecuté un punto de referencia basado en el ático. Las duraciones de las ejecuciones del ático (en las particiones de disco completo SMR de 8 TB) fueron:

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

En cada caso, los depósitos del ático tenían las siguientes estadísticas:

                       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

Agregar una segunda copia del mismo disco de 1 TB al ático tomó 4.5 horas en cada uno de estos tres sistemas de archivos. Un volcado sin procesar de los puntos de referencia y la smartctlinformación se encuentra en: http://pastebin.com/tYK2Uj76 https://github.com/gmatht/joshell/tree/master/benchmarks/SMR

Si rsync proviene de una unidad SMR, asegúrese de que el sistema de archivos esté montado read-onlyo con noatimeopción.

De lo contrario, la unidad SMR necesitará escribir una marca de tiempo para cada archivo que lea rsync, lo que provocará una degradación significativa del rendimiento (desde alrededor de 80 mb / s hasta 3-5 mb / s aquí) y el desgaste de la cabeza / ruido de clic.

Si ya tiene un trabajo rsync ejecutándose con bajo rendimiento, no hay necesidad de detenerlo, puede volver a montar el sistema de archivos fuente haciendo

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

El efecto no se verá de inmediato, tenga paciencia y espere de 10 a 20 minutos, hasta que la unidad haya terminado de escribir todos los datos que aún están en sus memorias intermedias. Este consejo se prueba y se prueba bien.

Esto también podría aplicarse al rsyncacceder a una unidad SMR, es decir, si el sistema de archivos intenta actualizar la marca de tiempo después de que el archivo se haya escrito completamente en el disco. Esto agita la carga de trabajo secuencial y se reescriben continuamente grandes bandas de datos, lo que contribuye al desgaste del disco. Lo siguiente puede ayudar:

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

Esto debe hacerse antes de ejecutar rsync; otros factores pueden hacer que esta opción sea insignificante, es decir, actualización FAT / MFT sin búfer, escrituras paralelas si el sistema de archivos está optimizado principalmente para SSD, etc.

Intente usar dd bs=32My luego cambiar el tamaño del sistema de archivos en el destino SMR, si desea hacer una copia de seguridad de los sistemas de archivos completos de todos modos (no es necesario tenerlo montado y ejecutar rsync para transportar todos y cada uno de los archivos en este caso).

El hardware real en uso era una unidad de consumidor SMR de 8 TB administrada por unidad Seagate. Su millaje puede variar con otro hardware.