Discos SAS con la caché de escritura apagada de fábrica: ×13 en escrituras con ZFS
Un pool ZFS de cinco discos hacía 95 escrituras con fsync por segundo, y un espejo de cuatro, 108. Varios discos venían con la caché de escritura desactivada. Activándola, sin comprar nada: 1.237 y 946.
- ZFS
- Linux (Debian, Alpine, Arch)
Comprobar
sdparm enseña el bit WCE (write cache enable) de cada disco. En varios de los míos estaba a 0: cada escritura esperaba a llegar al plato antes de confirmarse.
sdparm --get=WCE /dev/sdX
# Detrás de la bandeja SAS, los discos SATA no aceptan la orden normal
# («MODE SENSE command: Illegal request»): hay que usar la de 6 bytes.
sdparm --six --get=WCE /dev/sdX¿Es seguro con cortes de luz?
Con ZFS, sí. ZFS manda vaciar la caché del disco al cerrar cada grupo de transacciones y en cada escritura síncrona, así que un corte no deja el pool inconsistente. Lo que no toqué a propósito, porque hay cortes y no hay SAI: sync=standard y el intervalo de transacciones por defecto.
Activar y que dure
sdparm --set=WCE=1 --save /dev/sdX # SAS
sdparm --six --set=WCE=1 --save /dev/sdX # SATA tras la bandejaQue sobreviva al apagado
En los discos SATA detrás de un adaptador, el guardado no siempre sobrevive a un apagado completo, así que un servicio de systemd la vuelve a activar en cada arranque, identificando los discos por su WWN. Y una regla de udev pone el planificador «none» en los discos de ZFS: ZFS ya ordena y agrupa la E/S.
Medido con fio
- Pool RAIDZ1 de cinco discos: escritura aleatoria de 16K con fsync, de 95 a 1.237 IOPS (×13). La secuencial ya estaba limitada por el ancho de banda.
- Espejo de cuatro discos SAS: de 108 a 946 IOPS (×8,8) y la secuencial de 38 a 123 MB/s.
- Siempre en un dataset temporal sin compresión, borrado al terminar.