Чи можу вичерпати місце на диску, створивши дуже велику кількість порожніх файлів?

Загальновідомо, що порожні текстові файли мають нульовий байт:

Однак кожен з них містить метадані , які, згідно з моїми дослідженнями, зберігаються у inode та використовують простір .

З огляду на це, мені здається логічним, що можна заповнити диск, створивши чисто порожні текстові файли. Це правильно? Якщо так, то скільки порожніх текстових файлів мені потрібно буде заповнити диск, скажімо, 1 Гб?

Щоб зробити кілька перевірок, я запускаю, df -iале це, мабуть, показує% вживаних (?) Вкладень, а не скільки вони важать.

Filesystem             Inodes  IUsed    IFree IUse% Mounted on
udev                   947470    556   946914    1% /dev
tmpfs                  952593    805   951788    1% /run
/dev/sda2            28786688 667980 28118708    3% /
tmpfs                  952593     25   952568    1% /dev/shm
tmpfs                  952593      5   952588    1% /run/lock
tmpfs                  952593     16   952577    1% /sys/fs/cgroup
/dev/sda1                   0      0        0     - /boot/efi
tmpfs                  952593     25   952568    1% /run/user/1000
/home/lucho/.Private 28786688 667980 28118708    3% /home/lucho

Цей висновок пропонує 28786688загальні значення inode, після чого наступна спроба створити файл у кореневій файловій системі (пристрої /dev/sda2) повернеться ENOSPC("На пристрої не залишилось місця").

Пояснення: у оригінальному дизайні файлової системи * nix максимальна кількість входів встановлюється під час створення файлової системи. Для них виділено виділений простір. Ви можете не вистачати вкладки, перш ніж у вас не вистачить місця для даних, або навпаки. Найпоширеніша файлова система Linux за замовчуванням ext4все ще має таке обмеження. Для отримання інформації про розміри inode на ext4, дивіться на сторінці mankfs.ext4.

Linux підтримує інші файлові системи без цього обмеження. Увімкнено btrfs, простір розподіляється динамічно. "Структура inode порівняно невелика і не буде містити вкладених даних про файли чи розширені дані атрибутів." (ext3 / 4 виділяє деякий простір всередині inode для розширених атрибутів ). Звичайно, ви все ще можете вичерпати місце на диску, створивши занадто багато записів метаданих / каталогів.

Думаючи про це, tmpfs - це ще один приклад, коли індекси розподіляються динамічно. Важко дізнатись, що df -iнасправді означатиме максимальна кількість введених входів для цих файлових систем. Я б не надав жодного значення показаному значенню.

"XFS також розподіляє індекси динамічно. Так само і JFS. Так чи робив / робить reiserfs. Так само і F2FS. Традиційні файлові системи Unix виділяють іноди статично в mkfs час, і так роблять сучасні FS, як ext4, які відслідковують свою спадщину назад, але в наші дні це виняток, а не правило.

"BTW, XFS дозволяє вам встановити обмеження на максимальний відсоток місця, який використовується індексами, тож ви можете закінчитись з введеннями, перш ніж дійти до точки, коли ви не можете додати до існуючих файлів. (За замовчуванням 25% для FSes під 1 ТБ, 5% для файлових систем до 50 ТБ, 1% для більших, ніж це.) У будь-якому випадку, використання цього простору на метаданих (вклади та карти масштабів) буде відображено у регулярному режимі df -h", - Петро Кордес у коментарі до цієї відповіді

Створення порожніх файлів передбачає використання наступного:

• inodes, по одному на файл;
• додаткові записи каталогів, також по одному на файл, але зведені.

Кількість доступних входів часто визначається при створенні файлової системи, і її неможливо змінити (деякі файлові системи, такі як Btrfs або XFS, розподіляють іноди динамічно). Ось що вимірюється df -i. Коли у вас не вистачає вкладень, ви не можете створювати нові файли чи каталоги, навіть якщо у вас є місце на диску.

Записи в каталозі також займають місце з доступного місця на диску. Це можна побачити, переглянувши розмір каталогу: він завжди кратний розміру блоку, а коли каталог містить багато файлів, його розмір збільшується. Якщо у вас не вистачає місця на диску, ви, можливо, не зможете створити нові файли або каталоги в "повному" каталозі ( тобто додавання нового файлу передбачає виділення нового блоку), навіть якщо у вас є доступні вставки.

Так що так, вичерпати місце на диску можна лише за допомогою порожніх файлів.

Чистий логічний аргумент:

Ім'я файлу складається з ненульової кількості байтів. Навіть при теоретичному максимальному стисненні в гіпотетичній файловій системі, розробленій для забезпечення абсолютної максимальної кількості імен файлів, кожне ім’я файлу все одно буде споживати принаймні один біт десь на вашому фізичному диску. Можливо, і більше, але "1 біт на файл" - це тривіальний мінімум.

Обчисліть кількість бітів, яка, можливо, вміститься на вашій тарілці, і це теоретична максимальна кількість файлів (порожніх або не порожніх), які ви можете зберігати на ній.

Отже, відповідь - так. Врешті-решт у вас не вистачить місця, незалежно від того, який об'єм пам’яті ви використовуєте, якщо продовжувати додавати порожні файли. Очевидно, ви закінчитеся набагато швидше, ніж максимум, що розрахований таким чином, але вичерпаєтесь.

Просто ні, але ви можете закінчитись з inodes на Linux, який буде таким же, як і з простору.

ви можете спробувати щось подібне у своїй оболонці n=0; while :; do touch $n; let n=n+1; done

Просто переконайтеся, що запустіть його у віртуальній машині, інакше у вас буде дуже швидко.

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

(відповідь у коментарі Баарда Копперуда)