Почему нет системных вызовов для вставки файлов?

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

Почему в Linux нет системных вызовов для вставки или удаления контента в файлах?

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

С такими функциями файловой системы, как «копирование при записи» или «прозрачное сжатие файлов», текущий способ вставки содержимого кажется очень неэффективным.

files file-copy system-calls dercolamann
источник

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

Мосви

@mosvy, но используется ли концепция «создать новый файл, а затем переименовать», потому что она хороша сама по себе или именно потому, что система не обеспечивает лучшего способа? Особенно над текстовыми файлами такие операции, как «изменить эту строку (изменяя длину)» или «вставить эти строки здесь» довольно распространены, поэтому можно предположить, что операции с файловой системой для этих точных функций будут использоваться, если бы они были там. Конечно, отсутствие их делает реализацию fs намного проще ...

ilkkachu

@meuh OpenVMS по-прежнему работает через RMS (службы управления записями).

RonJohn

UNIX начал отказываться от предоставления систем управления записями внутри файловой системы.

user207421

@ilkkachu это хорошо само по себе, без сомнения ;-) Более того, если бы inode были неизменными, это делало бы реализацию совместного использования блоков, управления версиями и почти всего гораздо более эффективной (и гораздо более простой для размышления). Подумайте по аналогии, как все языки сценариев переключились на неизменяемые строки - но здесь я остановлюсь; трудно говорить о файловых системах и не звучать как шарлатанство ;-)

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байты.

mosvy
источник

«но с блоком (4096), а не с гранулярностью байтов» - блоки 4KiB очень распространены в ext4, но это не гарантируется. Ext4 поддерживает размеры блоков 1 КБ, 2 КБ и 4 КБ ; и я помню из ext2 дней, что на процессорах Alpha также поддерживалась 8KiB. Я не могу просто предположить, что блоки 4KiB, я боюсь.

Марсел

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

Мосви

После того, как вы отредактируете (где вы говорите, что это обычно 4 КБ), я полностью согласен! Моя проблема заключалась в том, что раньше он легко читался как «блоки всегда 4 КБ» , что может заставить людей сделать такое предположение и написать ошибочный код.

Марсель

Поскольку все современные файловые системы не требуют хранения файла в непрерывном блоке памяти,

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

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

ilkkachu
источник