El modo de diario predeterminado para Ext4 es data=ordered, que, según la documentación, significa que

"Todos los datos se envían directamente al sistema de archivos principal antes de que sus metadatos se envíen al diario".

Sin embargo, también existe la data=journalopción, lo que significa que

"Todos los datos se guardan en el diario antes de escribirse en el sistema de archivos principal. Habilitar este modo deshabilitará la asignación retrasada y la compatibilidad con O_DIRECT".

Entiendo que esto es así, el data=journalmodo registrará todos los datos y metadatos, lo que, a primera vista, parece significar que esta es la opción más segura en términos de integridad y confiabilidad de los datos, aunque tal vez no sea tanto por el rendimiento.

¿Debo optar por esta opción si la fiabilidad es la mayor preocupación, pero el rendimiento es mucho menor? ¿Hay alguna advertencia para usar esta opción?

Para el fondo, el sistema en cuestión está en un UPS y el almacenamiento en caché de escritura está deshabilitado en las unidades.

Sí, data=journales la forma más segura de escribir datos en el disco. Dado que todos los datos y metadatos se escriben en el diario antes de escribirse en el disco, siempre puede reproducir trabajos de E / S interrumpidos en caso de bloqueo. También deshabilita la función de asignación retrasada , que puede conducir a la pérdida de datos .

Los 3 modos se presentan en orden de seguridad en el manual :

1. datos = diario
2. datos = ordenado
3. datos = reescritura

También hay otra opción que puede interesarle:

commit=nrsec    (*) Ext4 can be told to sync all its data and metadata
                    every 'nrsec' seconds. The default value is 5 seconds.

La única advertencia conocida es que puede volverse terriblemente lenta. Puede reducir el impacto en el rendimiento deshabilitando la actualización del tiempo de acceso con la noatimeopción.

Este hilo es muy antiguo, pero sigue siendo relevante.

Queríamos fusionar muchas escrituras pequeñas en una base de datos MySQL, ejecutándose como una máquina virtual en KVM usando imágenes Ceph RBD.

Invitado: CentOS 6 VM's / etc / fstab:

/dev/sda1               /                       ext4    defaults,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,noatime,nodiratime,commit=60,data=journal,discard 1 1

El dispositivo '/ dev / sda' (1 TiB) está en un grupo NVMe comprimido con código de borrado comprimido, con un dispositivo de diario dedicado relativamente pequeño (128 MiB) en un grupo NVMe triple replicado.

A continuación, los comandos que utilizamos en un entorno de rescate:

Separar el diario:

tune2fs -O ^has_journal /dev/sda1;

Verifique el sistema de archivos en busca de inconsistencias:

fsck.ext4 -f -C 0 /dev/sda1;

Obtenga el tamaño del bloque:

tune2fs -l /dev/sda1;

Formatear dispositivo de diario dedicado (ADVERTENCIA):

El tamaño mínimo del diario debe ser 1024 * tamaño de bloque (utilizamos 128 MiB para estar seguros)

Establezca el tamaño del bloque para que coincida con el de / dev / sda1

mke2fs -O journal_dev -L root_journal /dev/sdb1 -b 4096;

Adjunte el dispositivo de diario dedicado al sistema de archivos:

tune2fs -j -J device=LABEL=root_journal /dev/sda1;

Configuración de MySQL:

[mysqld]
innodb_old_blocks_time = 1000           # Prevent buffer pool pollution. Default as of MySQL 5.6
innodb_buffer_pool_size = 24576M        # MySQL Cache
innodb_log_buffer_size = 128M           # 25% of log_file_size
innodb_log_file_size = 512M             # 25% of the buffer_pool (no, not really)
query_cache_size = 128M                 # Query Cache
table_cache = 512                       # Make it large enough for: show global status like 'open%';
#mysqltuner.pl:
innodb_flush_method = O_DSYNC           # Don't validate writes. MySQL 5.6+ should use O_DIRECT
innodb_flush_log_at_trx_commit = 2      # Flush MySQL transactions to operating system cache
join_buffer_size = 256K
thread_cache_size = 4
innodb_buffer_pool_instances = 16
skip-innodb_doublewrite