Кратковременные файлы сбрасываются на диск?

Моя программа создает много небольших недолговечных файлов. Как правило, они удаляются в течение секунды после создания. Файлы находятся в файловой системе ext4, поддерживаемой настоящим жестким диском. Я знаю, что Linux периодически сбрасывает ( pdflush) грязные страницы на диск. Поскольку мои файлы недолговечны, скорее всего они не кэшируются pdflush. У меня вопрос, вызывает ли моя программа много записей на диск? Моя забота - это жизнь моего жесткого диска.

Поскольку файлы небольшие, давайте предположим, что сумма их размеров меньше, чем dirty_bytesи dirty_background_bytes.

В Ext4 включен журнал по умолчанию, т.е. журнал метаданных. Я также хочу знать, записаны ли метаданные или данные на диск.

Простой эксперимент с использованием ext4:

Создать изображение размером 100 МБ ...

# dd if=/dev/zero of=image bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.0533049 s, 2.0 GB/s

Сделать это петлей устройства ...

# losetup -f --show image
/dev/loop0

Сделай файловую систему и смонтируй ...

# mkfs.ext4 /dev/loop0
# mount /dev/loop0 /mnt/tmp

Сделайте какой-нибудь запуск с недолговечными файлами. (Измените это на любой метод, который вы предпочитаете.)

for ((x=0; x<1000; x++))
do
    (echo short-lived-content-$x > /mnt/tmp/short-lived-file-$x
     sleep 1
     rm /mnt/tmp/short-lived-file-$x ) &
done

Размонтировать, синхронизировать, разблокировать.

# umount /mnt/tmp
# sync
# losetup -d /dev/loop0

Проверьте содержимое изображения.

# strings image | grep short-lived-file | tail -n 3
short-lived-file-266
short-lived-file-895
short-lived-file-909
# strings image | grep short-lived-content | tail -n 3

В моем случае он перечислил все имена файлов, но не содержимое файла. Так что только содержание не было написано.

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

Если вы действительно хотите избежать записи на диск, посмотрите tmpfs ,

Как правило, нет, они не будут написаны. Это связано с тем, что кэш сбрасывает грязные страницы при выполнении одного из двух условий:

1. Данные устаревают после /proc/sys/vm/dirty_writeback_centisecs, по умолчанию 5 секунд.

2. В кеше слишком мало памяти для хранения данных, больше, чем в dirty_ratioгрязных страницах (по умолчанию 20%).

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

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

Одна файловая система, в которой заметно интересующее вас поведение (так называемое «отложенное размещение») - это XFS. С его помощью вы можете быть более или менее уверены (если в другом месте нет забавных вариантов конфигурации), что блоки, принадлежащие только что удаленным файлам, будут повторно использоваться в памяти без промежуточного доступа к диску. XFS может по-прежнему хотеть обновить свой журнал метаданных (который будет записываться на диск довольно часто; тем не менее, учитывая, что журнал XFS является только метаданными, он достаточно мал, чтобы быть установленным на каком-то другом быстром устройстве, например, на найденном ОЗУ с резервным питанием от батареи). на многих RAID контроллерах).

Из-за этого поведения весьма часто можно найти полностью обнуленные, но в остальном законно выглядящие файлы (размер и другие метаданные без изменений) в файловой системе XFS после внезапного отключения питания. Такова стоимость поддержки быстрых «временных» файловых операций.

Немного теории

В общем, системный вызов, обращающийся к файловой системе, довольно быстро завершается в методе, определяемом драйвером файловой системы (присоединяется к «struct inode_operations» и «struct file_operations», когда VFS-драйвер зарегистрирован). То, что происходит после этого, остается исключительно на усмотрение реализации файловой системы. Обычно используется нечто похожее на следующий подход (этот простой пример взят из драйвера Linux FAT):

if (IS_DIRSYNC(dir))
    (void)fat_sync_inode(dir);
else
    mark_inode_dirty(dir);

Если файловая система смонтирована в режиме синхронизации, все изменения немедленно отправляются на диск (в данном случае через fat_sync_inode ()). В противном случае блок помечается как «грязный» и остается в кэше памяти, пока не будет сброшен при некоторой разумной возможности.

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