SSD, Borrar tamaño de bloque y LVM: PV en dispositivo sin formato, Alineación

Quiero instalar un nuevo SSD y usar todo el dispositivo como PV para LVM; en otras palabras: no planeo poner ni siquiera una partición en este dispositivo. Por lo tanto, no es necesario alinear particiones en los bloques de borrado.

Pregunta (s)

¿Es suficiente establecer --dataalignmentel tamaño del bloque de borrado cuando pvcreateing y --physicalextentsizeun múltiplo del tamaño del bloque de borrado cuando vgcreateing?

Entonces, suponiendo que mi SSD tenga un tamaño de bloque de borrado de 1024k, ¿está bien

• pvcreate --dataalignment 1024k /dev/ssd
• vgcreate --physicalextentsize $(( x * 1024 ))k ...

¿Algo más a tener en cuenta?

Suponiendo que pondría sistemas de archivos ext4 en los LV en este VG, sería una buena idea alinear las extensiones ext4 con el tamaño LVM-PE, ¿verdad? Entonces, ¿ext4-extents debe ser del mismo tamaño o un múltiplo de LVM-PE-size?

Gracias por cualquier aclaración!

Sí, también revisé todo el diseño en disco de MBR / PBR / GPT / MD / LVM, y llegué a la misma conclusión.

Para su caso (LVM en disco sin formato), si LVM-PE (extensión física) está alineado con 1 MB con pvcreate, puede estar seguro de que todas las asignaciones de datos posteriores estarán alineadas, siempre que mantenga el tamaño de la asignación en (1 MB * N) .

Dado que tanto "vgcreate -s" como "lvcreate -L" manejan el tamaño sin unidad como valor de MB por defecto, probablemente no necesite preocuparse mucho por la alineación una vez que haya realizado correctamente su pvcreate. Solo asegúrese de no dar el tamaño en% / PE (para lvcreate -l) y B (byte) / S (512B - el sector siempre es 512B en LVM) / K (KB) (para vgcreate -s y lvcreate -L).

=== añadido para aclaración ===

Solo como seguimiento, mientras que una SSD puede tener un tamaño de bloque de borrado de 1024 KB como un dispositivo completo, el tamaño de bloque de borrado / tamaño de página de rw de cada chip flash interno es probablemente de aproximadamente 32 KB-128 KB / 512B-8 KB.

Aunque esto depende del controlador de cada SSD, la penalización de E / S debido al ciclo adicional de lectura-modificación-escritura probablemente no sucederá siempre que mantenga su escritura alineada para borrar el tamaño de bloque de cada chip interno, que es 32KB-128KB arriba ejemplo. Es solo que desea que la solicitud de escritura única sea lo suficientemente grande (= borrar el tamaño de bloque de SSD como un dispositivo completo), por lo que puede esperar un mejor rendimiento al controlar de manera eficiente todos los chips / canales internos.

Entiendo que la alineación de 1024 KB es solo una medida de seguridad, ya que la función del chip controlador varía según el proveedor y las especificaciones del chip flash cambian rápidamente. Es más importante que la solicitud de escritura a nivel del sistema operativo se realice en un paquete grande (1024 KB, en este caso).

Ahora, dicho esto, hacer mkfs (8) en un bloque LVM alineado con 1 MB casi seguramente romperá la alineación de 1 MB para datos / metadatos a nivel de sistema de archivos. La mayoría de los sistemas de archivos solo se preocupan por hacer una alineación de 4KB, por lo que probablemente no sea perfecto para SSD (pero, IIRC, los archivos recientes como btrfs intentan mantener la alineación de 64 KB + al asignar un bloque contiguo interno). Pero muchos fs tienen una característica para agrupar escrituras (por ejemplo, configuración de tamaño de banda) para obtener el rendimiento de RAID, de modo que se pueda usar para hacer que la solicitud de escritura en SSD sea casi óptima.

Realmente quiero respaldar mi declaración con datos reales, pero fue realmente difícil de probar ya que el controlador SSD de hoy es tan inteligente y no mostrará mucha degradación del rendimiento una vez que el tamaño de alineación y el tamaño de escritura sean "lo suficientemente grandes". Solo asegúrese de que no esté mal alineado (evite la alineación <4KB a toda costa) y que no sea demasiado pequeño (1024 KB es lo suficientemente grande).

Además, si realmente le importa la penalización de E / S, verifique dos veces deshabilitando la memoria caché del dispositivo y comparando con la prueba sincronizada de lectura, escritura y reescritura.

A mi entender, los valores predeterminados ya son lo suficientemente buenos. No creo que deba preocuparse por la opción --dataalignment, ya que LVM intentará alinear automáticamente todo según los valores exportados por sysfs; consulte la opción "data_alignment_detection" en lvm.conf:

# By default, the start of a PV's data area will be a multiple of
# the 'minimum_io_size' or 'optimal_io_size' exposed in sysfs.
# - minimum_io_size - the smallest request the device can perform
#   w/o incurring a read-modify-write penalty (e.g. MD's chunk size)
# - optimal_io_size - the device's preferred unit of receiving I/O
#   (e.g. MD's stripe width)
# minimum_io_size is used if optimal_io_size is undefined (0).
# If md_chunk_alignment is enabled, that detects the optimal_io_size.
# This setting takes precedence over md_chunk_alignment.
# 1 enables; 0 disables.
data_alignment_detection = 1

Además, no es necesario especificar un tamaño de material físico para crear vg, ya que el valor predeterminado ya es de 4 MB.