Ext4的默认日记模式是data=ordered，根据文档，这意味着
“在将元数据提交到日志之前，所有数据都被直接强制发送到主文件系统。”
但是，还有data=journal选项，这意味着
“所有数据在写入主文件系统之前都已提交到日志中。启用此模式将禁用延迟分配和O_DIRECT支持。”
我对此的理解是，该data=journal模式将记录所有数据以及元数据，从表面上看，这似乎意味着就数据完整性和可靠性而言，这是最安全的选择，尽管对于性能而言可能并不那么重要。
如果可靠性是最重要的问题，但性能却要差得多，我应该选择该选项吗？使用此选项是否有任何警告？
对于后台，相关系统在UPS上，并且驱动器上的写缓存被禁用。
Answers:
是的，这data=journal是将数据写入磁盘的最安全方法。由于所有数据和元数据在写入磁盘之前都已写入日志，因此在发生崩溃时始终可以重播中断的I / O作业。它还禁用了延迟分配功能，这可能导致数据丢失。
手册中以安全性顺序介绍了3种模式：
还有一种可能会让您感兴趣的选择：
commit=nrsec (*) Ext4 can be told to sync all its data and metadata
every 'nrsec' seconds. The default value is 5 seconds.
唯一已知的警告是它可能变得非常缓慢。您可以通过使用noatime选项禁用访问时间更新来减少性能影响。
该线程是旧的，但仍然有用。
我们想要合并许多MySQL数据库上的小写内容，并使用Ceph RBD映像在KVM下作为VM运行。
来宾：CentOS 6 VM的/ etc / fstab：
/dev/sda1 / ext4 defaults,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,noatime,nodiratime,commit=60,data=journal,discard 1 1
“ / dev / sda”设备（1 TiB）位于压缩擦除编码的NVMe池中，而相对较小的（128 MiB）专用日志设备位于三重复制的NVMe池中。
此处提供了我们在救援环境中使用的命令：
分离日志：
tune2fs -O ^has_journal /dev/sda1;
检查文件系统是否存在不一致：
fsck.ext4 -f -C 0 /dev/sda1;
获得块大小：
tune2fs -l /dev/sda1;
格式化专用日志设备（警告）：
mke2fs -O journal_dev -L root_journal /dev/sdb1 -b 4096;
将专用日志设备连接到文件系统：
tune2fs -j -J device=LABEL=root_journal /dev/sda1;
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
data=journal能提供比data=ordered+ 更安全的结果的情况nodelalloc。你是否有一个？