Чи стикаються на диск короткочасні файли?

Моя програма створює багато невеликих короткочасних файлів. Зазвичай вони видаляються протягом секунди після створення. Файли знаходяться у файловій системі 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, sync, unloop.

# 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 зареєстрований). Що після цього залишається виключно на розсуд щодо реалізації файлової системи. Зазвичай використовується щось, що нагадує такий підхід (цей простий приклад - з драйвера FAT Linux):

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

Якщо файлова система встановлена ​​в режимі «синхронізації», всі зміни негайно переходять на диск (через fat_sync_inode () у цьому випадку). В іншому випадку блок позначається як "брудний" і залишається в кеш-пам'яті до тих пір, поки не змиється за певної розумної можливості.

Таким чином, неможливо передбачити поведінку системи щодо перехідних файлів, не враховуючи параметри кріплення файлової системи та не перевіряючи вихідний код її реалізації (це, звичайно, стосується в основному всіх видів екзотичних файлових систем, що знаходяться в основному у вбудованому просторі) .