Как долго можно кэшировать записи в файловой системе с помощью ext4?

Question

Некоторое время назад была некоторая дискуссия о том, что ext4 может оставить пустые файлы после нечистого размонтирования, что довольно хорошо описано в этой статье. В основном из-за отложенного размещения записи могут храниться в кэше записи гораздо дольше, чем интервал фиксации по умолчанию для журнала ext (5 секунд).

Похоже, что проблемы были исправлены в патче, который принудительно распределяет блоки в определенных ситуациях, тем самым вынуждая данные переноситься на диск максимум через 5 секунд по умолчанию.

Мне интересно, что происходит, когда приложение перезаписывает существующие части файла без усечения или добавления самого файла. Будет ли это записано на диск в течение 5 секунд?

Это похоже на ситуацию, отличную от добавления к файлу: при добавлении размер файла изменяется, что является изменением метаданных; следовательно, фиксация журнала будет необходима в течение 5 секунд, и из-за данных = заказанные данные должны будут быть записаны до этого из-за соображений безопасности (в противном случае части удаленных файлов других пользователей могут отображаться для владельца добавленной файл).

При простой перезаписи данных файла нет причин, по которым запись данных должна происходить до фиксации журнала метаданных, поскольку старые данные принадлежат тому же пользователю, что и новые. Так происходит ли запись перед фиксацией в любом случае, или она может быть отложена дольше интервала фиксации журнала? Если да, то как долго?

Обновление: я знаю, что все это не имеет значения, когда вы делаете правильные вещи, то есть используете fsync(). (Это было основной причиной всех дискуссий о ext4 и потере данных - проблема касалась только приложений, не работающих с fsync() или не в нужные моменты.) Я не пишу свое собственное приложение, я спрашиваю, потому что я не знаю, все ли мои приложения работают правильно, и я хочу знать приблизительный срок для таких "опасных" записей. Причина для того, чтобы спросить, заключается в том, что мой графический драйвер регулярно вызывает панику в ядре, и я хочу знать, нужно ли мне беспокоиться о том, что запись данных занимает более 5 секунд.

Answer 1

Вы можете установить интервал фиксации на пользовательское значение, которое, как я полагаю, может достигать 32-разрядного целого числа без знака в секундах; так около 4 миллиардов секунд или 136 лет. Это доступно через опцию commit монтирования, которую вы можете применить следующим образом (это просто пример; вы также можете установить это в fstab):

mount /dev/sda1 -t ext4 -o rw,data=writeback,nobh,commit=12345678

Интервал принятия не основан на каком-либо типе условия, например, добавлены ли данные или перезаписаны существующие данные или что-то еще. Параметр commit монтирования (который по умолчанию равен 5 секундам, если вы вообще не предоставляете опцию монтирования) эквивалентен выполнению чего-то подобного в оболочке bash:

#!/bin/bash
while :
do
    echo "Syncing all uncommitted data and journal to disk"
    sync
    sleep 5
done

Не путайте data=ordered и этот глобальный интервал синхронизации файловой системы ("интервал фиксации", возможно, является менее значимым термином для тех из нас, кто понимает функциональность sync командной строки, и в этом случае его лучше назвать "синхронизация"). интервал "). data=ordered order указывает на порядок обновления данных и метаданных (где data=writeback «менее безопасен / быстрее», а data=journal «более безопасен / медленнее»). commit=12345678 - это частота, с которой драйвер файловой системы сам выполняет ПОЛНУЮ синхронизацию ВСЕХ грязных данных / журнала / метаданных / любых данных на физическом носителе. И вы наверняка можете установить его на 136 лет, если хотите, и монтировать с data=writeback,nobh и программы, которые не вызывают fsync() или sync() будут иметь грязные страницы в ОЗУ в течение ... нескольких жизней.

Обновление: Исходя из вашего контекста в редактировании вашего вопроса, я бы сказал, что вы должны запустить свою файловую систему с параметрами монтирования data=journal,commit=1 или даже с опцией монтирования sync , пока не сможете разрешить панику ядра графического драйвера , Это обеспечит максимальную целостность данных, но за счет производительности. Вы особенно захотите сделать это, если вы часто записываете на диск данные, которые вы не можете позволить себе потерять, и это вдвойне важно, если вы не "доверяете" приложениям, которые вы используете для надлежащего использования fsync() .

Источник: здесь и личный опыт

Answer 2

Каким бы ни был ответ на ваш вопрос, это не имеет значения.

Гарантированное поведение файловой системы ext4 заключается в том, что «данные будут на диске после успешного вызова sync/fsync ». Итак, если у вас есть приложение, которое заставляет вас задать этот вопрос, вы должны вставить вызовы синхронизации в критические точки, где необходимо обеспечить целостность данных. Если вас беспокоит та же проблема, вы можете вызвать утилиту командной строки sync прежде чем предпринимать опасные действия, которые могут привести к нечистому завершению работы.