md raid5 extremadamente lento al descartar

md raid5 extremadamente lento al descartar

Hola a todos los expertos en md raid.

Ejecuto Centos 8 (con todas las actualizaciones más recientes, kernel 4.18.0-240.1.1.el8_3.x86_64) donde tengo 3x2T Samsung SSD 860 QVO 2TB en raid5 (para usar como base para algunas máquinas virtuales KVM) y cuando hago algo que Implica descartar, no sólo es lento, sino que es mucho más que utilizable. Creé un LV de 1.5T y luego hice "mkfs.ext4". Después de 4 h, la etapa de descarte me dijo "Descartando bloques de dispositivo: 10489856/409148416" y al principio estaba pensando "4 h para 25%, esto apesta", pero luego Me di cuenta de que es solo el 2,5%, ¡así que estamos hablando de una semana!

Rompí la incursión y descarté en las 3 unidades individuales, me tomó alrededor de 18 segundos cada una.

El hardware es un HP Proliant DL380p Gen8 con un controlador Smart Array P420i (sin controladores especiales, todos usan controladores Centos estándar) que configuré para el modo HBA, por lo que debería ser solo un paso (no se admite el descarte en absoluto si se usa hw). Redada).

Después de descartar los dispositivos, creé la incursión nuevamente con

mdadm --create /dev/md20 --level=5 --raid-devices=3 --chunk=64 /dev/sd{b,d,e}1

Lo dejé toda la noche para sincronizarlo. Luego creé un vg y probé la creación de lv, me tomó 7 minutos descartar 100M.

root@terrok:~ # lvcreate -nDELME -L100M vgssd2  && date && time mkfs.ext4 /dev/vgssd2/DELME && date && time lvremove -f /dev/vgssd2/DELME;date
  Logical volume "DELME" created.
Mon Dec 21 12:47:42 EST 2020
mke2fs 1.45.6 (20-Mar-2020)
Discarding device blocks: done
Creating filesystem with 102400 1k blocks and 25688 inodes
Filesystem UUID: f7cf3bb6-2764-4eea-9381-c774312f463b
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345, 73729

Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done


real    7m20.095s
user    0m0.004s
sys     0m0.195s
Mon Dec 21 12:55:02 EST 2020
  Logical volume "DELME" successfully removed

real    7m17.881s
user    0m0.018s
sys     0m0.120s
Mon Dec 21 13:02:20 EST 2020
root@terrok:~ #

Como comparación, en el mismo sistema también tengo dos WDC WDS100T2B0A-00SM50 (1T SSD) en raid1 y allí el descarte funciona mucho más rápido, 4 segundos para 10G.

Luego tomé dos de los SSD de Samsung y los descarté a toda velocidad. Repetido para las otras dos combinaciones de unidades y sin problemas. Para mí, esto apunta a algún problema con raid5. Por ahora tengo dos de los SSD en raid1 con un repuesto dinámico y esto al menos funciona pero, por supuesto, es 2T menos de espacio del que contaba.

¿Alguna sugerencia sobre lo que puedo hacer para que esto se pueda utilizar con raid5?

Respuesta1

Como lo demuestran sus pruebas, RAID5 es, de hecho, operaciones más intensivas que una simple matriz RAID 1. Porque RAID 1 literalmente simplemente se sincroniza entre dos discos, eso es todo.

RAID 5, por otro lado, tiene que hacer todos estos cálculos entre tres discos.yigualarlos. Eso es mucho trabajo, al menos en comparación con una matriz RAID 1 "simple".

Además, como barra lateral, las unidades QVO no son ideales para cargas como el mantenimiento de máquinas virtuales, cuyas actividades por lo general son escasas. Tampoco lo son las matrices de paridad como RAID 5 y demás. Es posible que desee reconsiderar sus estrategias de implementación dicho esto y la situación con RAID5 en sí.

Respuesta2

Acabo de abordar este tema también. Indagué en el controlador de raid5 y descubrí que raid5 divide la solicitud de descarte entrante en solicitudes de descarte de 4k en los dispositivos subyacentes. Además, lleva bastante tiempo roto, por lo que prácticamente ignora devices_handle_discard_safely. Como resultado, todos los descartes de 4k se sincronizan con el dispositivo subyacente, lo que hace que la operación sea aún más lenta en total. nota al margen: lo traeré a LKML pronto, para que puedan estar atentos allí. No estoy familiarizado con ninguna solución alternativa disponible con los núcleos existentes.

información relacionada