Alineación de particiones

La alineación de particiones es un aspecto muy importante ya que si no se realiza de forma correcta el rendimiento puede verse afectado negativamente, esto es debido a que se ha migrado de un tamaño de bloque de 512bytes a 4Kb, esto nos aporta varias ventajas:

• Mayor capacidad de almacenamiento útil: Se reduce el número de cabeceras CRC

• Mayor tolerancia a errores en el disco: Códigos CRC mas avanzados

• Mayor eficiencia: El tamaño de página habitual en SO actuales es de 4Kb(getconf PAGESIZE), por lo tanto volcar una página de RAM a disco solo debería de necesitar un acceso a disco

Conforme se va aumentando la densidad de almacenamiento la posibilidad de leer incorrectamente un sector aumenta ya que un error de 100 nanometros equivale a mas sectores que antes, esto hace que se necesiten mas sectores solo para CRC.
Si los sectores son mas grandes se puede hacer el crc de todo el bloque ahorrando espacio, además se puede repartir la info CRC a lo largo del disco haciendolo mas resitente a errores.

Por otra parte un tamaño de bloque mayor implica una fragmentación interna mayor, si la unidad mínima de datos es de 4Kb y mis ficheros son de 1Kb estoy desperdiciando 3Kb por cada fichero, pero el ahorro ganado por la mejora de los códigos CRC compensa,

Por motivos de retrocompatibilidad se creó una capa intermedia 512e que emula los 512bytes, así el software viejo sigue funcionando sin ningún problema.
Las lecturas no suelen verse afectadas ya que se leen los 4kb del sector y se parte en pedacitos de 512bytes para presentarselo a la app, en cambio con las escrituras se puede llegar a ver afectado en un 10%, se leen los 4kb modifica los 512bytes modificados por la app y escribe los 4k a disco.

Y esto no es todo, si además sumamos que las particiones pueden estar desalineadas el rendimiento puede verse gravemente afectado, en la siguiente figura podemos observar la desalineación:

Si recordamos el tamaño de página de Linux es de 4Kb, y el tamaño de sector de los discos duros actuales también, por lo tanto una lectura/escritura en disco debería equivaler a un solo acceso a este, pero si la partición no está alineada como es debido como en la imagen para hacer la escritura/lectura se han necesitado dos accesos a disco.

El desalineado suele ser debido a que la MBR consume los primeros 512bytes del disco(el primer sector en discos antiguos), de este modo todo queda desalineado, otro caso podría ser el haber creado las particiones desalineadas mediante alguna herramienta de particionado, pero esto es mas improbable ya que estas procuran no cometer este error.

Como a nivel físico los sectores son de 4k(o no, en SSDs puede variar) todas las particiones deberían comenzar en posiciones multiplos de 8: 512bytes * 8 = 4K
Los primeros 512bytes son ocupados por la MBR por lo tanto el primer sector físico se decarta: 4K y se creará la primera partición en los 8 siguientes sectores de 512bytes(segundo sector físico).

NOTA: En los SSDs la situación se agrava con la doble lectura ya que la vida del disco es limitada!!

Podemos saber el tamaño del sector físico mediante:

cat /sys/block//queue/physical_block_size

Y el tamaño del sector lógico(el que se le presenta al SO) con:

cat /sys/block//queue/logical_block_size

Las herramientas de identificación NO son fiables ya que el firmware del disco duro podría estar falseandola, lo mejor es buscar el modelo y consultar al fabricante.

cat /sys/block/sdX/device/model

Para comprobar el alineado de las particiones existentes los sectores de inicio deben de ser multiplos de 8(8x512=4K):

fdisk -l /dev/sda
Disposit. Inicio Start Final Blocks Id System
/dev/sda1 2048 1026047 512000 83 Linux
/dev/sda2 1026048 5220351 2097152 82 Linux swap / Solaris
/dev/sda3 5220352 976773167 485776408 83 Linux

/dev/sda1             2048   1026047    512000  83 Linux
python -c "print 2048/float(8)"
256.0

/dev/sda2          1026048   5220351   2097152  82 Linux swap / Solaris
python -c "print 1026048/float(8)"
128256.0

/dev/sda3          5220352 976773167 485776408  83 Linux
python -c "print 5220352/float(8)"
652544.0

Como todos son multiplos de 8 están bien alineadas :)

Que las particiones estén bien alineadas es solo el primer paso, cada una de las capas se van apilando una encima de la otra y todas cuentan:

APP --> FS --> RAID/LVM --> HD

Seguiremos con la configuración del RAID/LVM, sistema de ficheros y finalmente la aplicación.

El siguiente paso será hacer que la controladora RAID o softRAID lea en bloques multiplos de 8 también:

mdadm --create /dev/md3 --level=1 --chunk=128 --raid-devices=2 /dev/sda3 /dev/sdb3

--chunk=128
python -c "print 128/float(8)"
16.0

NOTA: Si las particiones no están alineadas se pueden rectificar cuando se haga un LVM.
Por ejemplo con un chunk en el RAID de 256k y una desalineación de 11 sectores, (1 sector = 512 bytes -- 1sector nuevo = 4kb=8sectores viejos).

Se ha desfasado 11sectores el próximo punto de alineación es a los 16 sectores.
16sectores = 11sectores que ya teniamos + X:5

pvcreate --dataalignmentoffset 5s --dataalignment 256k /dev/sdb1

NOTA: Además si se utiliza LVM y no se crean particiones si no que se meten discos enteros sin particionar el alineado queda solucionado de forma automática :)

Finalmente configuramos el sistema de ficheros dependiendo de los datos del raid.
Podemos sacar el tamaño de bloque de un sistema de ficheros mediante:

blockdev --getbsz /dev/sda1
4096 --> 4k

Según el tamaño de chunk de la controladora y el tamaño bloque del sistema de ficheros generaremos el sistema de ficheros con los parámetros:
ext4:  -E stride,stripe-width

Por ejemplo con un chunk de 128k:
stride=128k/4k(tamaño de bloque de ext4 por defecto)=32
stripe-width=NUMERO DE DISCOS CON DATOS EN EL RAID * stride
En nuestro RAID1: 2*32=64

NOTA: NUMERO DE DISCOS CON DATOS EN EL RAID -> No contamos los discos de paridad, solo datos puros

Según el sistema de ficheros elegido lo generaremos del siguiente modo:

mkfs.ext4 -b 4096 -E stride=32 -E stripe-width=64 -O dir_index /dev/XXXX
mkfs.xfs -b size=4k -d su=32k,sw=5 /dev/ice (alternatively you can specify sunit=X,swidth=Y as options when mounting the device)

Finalmente se configurará la app, MySQL por defecto utiliza páginas de 16KB para InnoDB, logs InnoDB de 128K y MyISAM 8K

En resumen quedaría del siguiente modo:
APP --> FS --> RAID --> HD
16KInnoDB --> 4KBExt4 --> 32KBRAID --> 4KBHD

• La app vuelca de RAM al sistema de ficheros en bloques de 16K

• El sistema de ficheros parte los 16K en pedacitos de 4 => 4 accesos a disco!

• La controladora acumula datos hasta los 32K para volcar a disco

• En el disco se escriben los 32K por sectores de 4K

Es recomendable que el tamaño de sector del sistema de ficheros coincida con el de la app, de este modo con un solo acceso a disco se realiza un volcado de datos de la app.