La modalità journal predefinita per Ext4 è data=orderedche, secondo la documentazione, significa che

"Tutti i dati vengono forzati direttamente nel file system principale prima che i loro metadati vengano inseriti nel journal."

Tuttavia, c'è anche l' data=journalopzione, il che significa che

"Tutti i dati vengono inseriti nel journal prima di essere scritti nel file system principale. L'abilitazione di questa modalità disabiliterà l'allocazione ritardata e il supporto O_DIRECT."

La mia comprensione di questo è che la data=journalmodalità registrerà tutti i dati e i metadati, il che, a prima vista, sembra significare che questa è l'opzione più sicura in termini di integrità e affidabilità dei dati, anche se forse non tanto per le prestazioni.

Dovrei scegliere questa opzione se l'affidabilità è la massima preoccupazione, ma le prestazioni lo sono molto meno? Ci sono avvertenze sull'uso di questa opzione?

Per lo sfondo, il sistema in questione si trova su un UPS e la memorizzazione nella cache è disabilitata sulle unità.

Sì, data=journalè il modo più sicuro di scrivere dati su disco. Poiché tutti i dati e i metadati vengono scritti sul journal prima di essere scritti su disco, è sempre possibile riprodurre i processi di I / O interrotti in caso di arresto anomalo. Disabilita anche la funzione di allocazione ritardata , che può portare alla perdita di dati .

Le 3 modalità sono presentate in ordine di sicurezza nel manuale :

1. data = journal
2. Dati = ordinato
3. data = writeback

C'è anche un'altra opzione che potrebbe interessarti:

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

L'unica avvertenza nota è che può diventare terribilmente lento. È possibile ridurre l'impatto sulle prestazioni disabilitando l'aggiornamento del tempo di accesso con l' noatimeopzione.

Questa discussione è super vecchia, ma comunque rilevante.

Volevamo unire molte piccole scritture su un database MySQL, in esecuzione come VM sotto KVM usando immagini Ceph RBD.

Ospite: 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

Il dispositivo '/ dev / sda' (1 TiB) si trova in un pool NVMe codificato con cancellazione cancellata, con un dispositivo journal dedicato relativamente piccolo (128 MiB) in un pool NVMe triplo replicato.

Con la presente i comandi che abbiamo usato in un ambiente di salvataggio:

Stacca il diario:

tune2fs -O ^has_journal /dev/sda1;

Controllare il file system per incoerenze:

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

Ottieni la dimensione del blocco:

tune2fs -l /dev/sda1;

Formatta dispositivo journal dedicato (ATTENZIONE):

La dimensione minima del journal deve essere di 1024 * (per sicurezza, utilizziamo 128 MiB)

Imposta la dimensione del blocco in modo che corrisponda a quella di / dev / sda1

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

Collegare il dispositivo journal dedicato al file system:

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

Impostazioni 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