Как долго можно записывать в файловую систему файлы ext4?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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