Вопросы Теги

Действительно ли data=journal более безопасен для Ext4 в противоположность data=ordered?

От shutter-project.orgстраница (1) загрузки:

Red Hat Enterprise Linux (и Производные как CentOS, Научный Linux и т.д.)

Один из наших пользователей (Nux) обеспечивает небольшой репозиторий для RHEL 6. Репозиторий разработан для сосуществования с репозиторием Fedora EPEL. Для добавления тех repos к системе и Затвору установки, можно использовать следующие команды:

rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-5.noarch.rpm
rpm -Uvh http://li.nux.ro/download/nux/dextop/el6/x86_64/nux-dextop-release-0-1.el6.nux.noarch.rpm 
yum install shutter

Это могло работать.

(1) первый Google результата представляет для "песней затвора".

37
30.04.2014, 12:42
2 ответа
[1127720]Да, [1128085]data=journal[1128086] - это самый безопасный способ записи данных на диск. Поскольку все данные и метаданные перед записью на диск записываются в журнал, в случае сбоя всегда можно повторить прерванные задания ввода/вывода. Он также отключает функцию [1128087]отложенного распределения [1128088], которая [1128089] может привести к потере данных [1128090].

Эти 3 режима представлены в порядке безопасности в [1128091]manual[1128092]:

data=journal

enter image description here

data=ordered

enter image description here

data=writeback

#mkdir /media/myusbstick
#mount /dev/disk3 /media/myusbstick
# cd /media/myusbstick

Есть также еще один вариант, который может вас заинтересовать:

Единственное известное предостережение - это то, что он может стать ужасно медленным. Вы можете уменьшить влияние на производительность, отключив обновление времени доступа с помощью опции [1128099]noatime[1128100].[1127729].

31
27.01.2020, 19:36

Тема очень старая, но все еще актуальная.

Мы хотели объединить множество крошечных операций записи в базе данных MySQL, работающей как виртуальная машина под управлением KVM с использованием образов Ceph RBD.

Гость :CentOS 6 /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 ТиБ )находится в сжатом пуле NVMe с затирающим кодированием, а относительно крошечное (128 МБ )выделенное устройство журнала находится в пуле NVMe с тройной репликацией.

При этом команды, которые мы использовали в среде восстановления:

Отсоединить журнал:

tune2fs -O ^has_journal /dev/sda1;

Проверить файловую систему на наличие несоответствий:

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

Получить размер блока:

tune2fs -l /dev/sda1;

Форматировать специальное журнальное устройство (ПРЕДУПРЕЖДЕНИЕ):

Минимальный размер журнала должен быть 1024 *размер блока (мы используем 128 МБ на всякий случай)

Установите размер блока, соответствующий размеру /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
4
27.01.2020, 19:36

Теги

Похожие вопросы