Чому немає системних дзвінків для вставки файлів

Наскільки я розумію, для управління файлами існує лише sys_write syscall в Linux, який перезаписує вміст файлу (або розширює його, якщо в кінці).

Чому немає системних викликів для вставки або видалення вмісту у файли в Linux?

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

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

files file-copy system-calls

— дерколаман
джерело

Як і у всіх фантазійних файлових операціях, така операція на практиці є набагато менш корисною, ніж здається. Основне використання для такої речі - дуже спеціалізовані програми, такі як бази даних, емулятори тощо. Спосіб, яким ви зазвичай «редагуєте» файл, - це створити новий файл і виконувати операцію «збереження», перейменувавши новий файл на старий.

— mosvy

@mosvy, але чи використовується концепція "створити новий файл, потім перейменуй", тому що це добре саме по собі, або саме тому, що система не забезпечує кращого способу? Особливо в текстових файлах такі операції, як "змінити цей рядок (змінивши довжину)" або "вставити ці рядки сюди" є досить поширеними, тому можна припустити, що операції з файловою системою для цих точних функцій будуть використовуватися, якби вони були там. Звичайно, відсутність їх робить виконання FS набагато простішим ...

— ilkkachu

@meuh OpenVMS все ще відбувається через RMS (Services Management Services).

— РонДжон

UNIX почав відходити від надання систем управління записами всередині файлової системи.

— користувач207421

@ilkkachu це добре саме по собі, абсолютно без сумніву ;-) Навіть більше, якщо inodes були незмінні, це зробить реалізацію блоку, версію версій та майже все набагато ефективнішим (і набагато простіше міркувати). Подумайте за аналогією, як усі мови скриптів перейшли на незмінні рядки - але я скорочу це; важко розмовляти манжетою про файлові системи і не звучати як шарлатан ;-)

— mosvy

Відповіді:

На останніх системах Linux, що насправді можливо, але з блоком (4096 більшу частину часу), не деталізація байтів , а лише в деяких файлових системах (ext4 і xfs).

Цитування з сторінки сторінки fallocate(2):

int fallocate(int fd, int mode, off_t offset, off_t len);

[...]

Збір файлового простору

Вказівка FALLOC_FL_COLLAPSE_RANGEпрапора (доступна з Linux 3.15) у modeфайлі видаляє діапазон байтів, не залишаючи лунки. Діапазон байтів, який потрібно згортати, починається offsetз len байтів і продовжується . По завершенні операції вміст файлу, що починається з місця, offset+lenбуде доданий у місце розташування offset, а файл буде на lenменше байтів.

[...]

Збільшення файлового простору

Вказівка FALLOC_FL_INSERT_RANGEпрапора (доступна з Linux 4.1) modeзбільшує файловий простір, вставляючи отвір у розмірі файлу, не перезаписуючи жодних існуючих даних. Отвір почнеться offsetі продовжується для lenбайтів. Під час вставлення отвору всередині файлу вміст файлу, що починається з, offsetбуде зміщений вгору (тобто, до більш високого зміщення файлу) на lenбайти. Вставлення отвору всередині файлу збільшує розмір файлу в lenбайтах.

— мосви
джерело

"але з блоком (4096), а не байтовістю" - 4KiB блоки дуже поширені в ext4, але це не гарантується. Ext4 підтримує розміри блоків 1KiB, 2KiB та 4KiB ; і я пам'ятаю з ext2 днів, що на процесорах Alpha також підтримувалася 8KiB. Боюся, ви не можете просто припустити, що блоки є 4 Кбіт.

— marcelm

4k (що за замовчуванням) є кратним 1k і 2k, тому немає жодних проблем з припущенням 4k з ext4. Хоча xfs за замовчуванням також до 4k, він повинен підтримувати bs, більший за 4k - до 64k, але мені вдалося створити лише такий fs - встановлення не вдається без ENOSYS. І в будь-якому випадку, ви нічого не можете припустити - ця функція підтримується не на всіх fs, тому краще просто сказати блок = 4096, щоб читач мав певне відчуття пропорції, а не дозволяв йому плавати і не дозволяти людям, щоб це було чим завгодно, або ще гірше, що це 512 байт або якимось чином пов’язаний з розміром сторінки vm.

— mosvy

Після редагування (де ви говорите, що це зазвичай 4KiB), я повністю згоден! Моя проблема полягала в тому, що раніше її було легко читати як "блоки завжди є 4 КБ" , що може змусити людей зробити таке припущення і написати помилковий код.

— marcelm

Оскільки всі поточні файлові системи не вимагають збереження файлу в безперервному блоці пам'яті,

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

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

— ілкака
джерело