Какие файловые системы позволяют изменить положение начала файла?

Типичные файловые системы и интерфейс POSIX позволяют изменять размер файла в конце. Обычно размер файла "на диске" после его закрытия равен смещению позиции чтения/записи, когда он был закрыт. Поиск перед закрытием также известен как "перестановка конца файла".

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

Является ли это прямой поддержкой любого распространенного формата файловой системы и/или операционной системы? Какой интерфейс используется для этого? (Например, селектор Linux fcntl.) Я почти уверен, что слышал об этом на практике.

Ответ 1

На самом деле Linux имеет интерфейс, который выполняет то, что вы запрашиваете. Это флаг FALLOC_FL_COLLAPSE_RANGE. Он поддерживается btrfs, ext4 и xfs (возможно, другими) на современных ядрах. Хотя интерфейс fallocate позволяет вам указывать смещения байтов и длины, на практике вызов COLLAPSE_RANGE будет работать, только если смещение и длина кратны размеру блока файловой системы.

Для получения дополнительной информации см. Fine Manual для системного вызова fallocate (2): http://man7.org/linux/man-pages/man2/fallocate.2.html

Ответ 2

Нет. Во всяком случае, в мире Unix.

Если вы заглянете внутрь внутренних систем СУБД или Unix (ish), они могут легко усекать или расширять наборы данных в начале, в конце или в любом месте посередине. Но они не экспортируют эту функциональность; он не является частью наследия Unix API или стандартом POSIX, поэтому любые "обрезанные в начале" или "расширяться в начале" API будут нестандартными ( "проприетарными" ).

Предельная полезность таких функций также неясна. Кто их будет использовать? Как часто?

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

Unix-разработчики использовали аргументы, что "все вещи могут быть сведены к файлам" и "мы можем получить случайный доступ за счет умного поиска". Тем не менее, эти претензии никогда не были разработаны. Unix никогда, например, не сопоставлял возможности управления записью произвольного доступа для миникомпьютеров и операционных систем мейнфреймов (например, DEC RMS, IBM ISAM и VSAM). И хотя те, которые реализуют файловые системы, очереди, попытки, реляционные базы данных и хранилища объектов, иногда отбрасывают содержимое в файлы и используют файлы для последовательных операций, таких как ведение журнала, но они редко зависят от потоков символов как их низкоуровневого формата. Вместо этого они используют структуры типа B-деревья и хеш-таблицы для непосредственного управления блоками диска, сегментами памяти и другими основными ресурсами.

Потоки символов относятся к таблицам, документам и объектам - абстракциям, подходящим для клиентских приложений. Если вам нужна очередь, рассмотрите возможность использования существующего промежуточного программного обеспечения (например, RabbitMQ, ZeroMQ, REDIS, некоторого менеджера СУБД), который уже охватывает это. Если вы должны построить его самостоятельно, вы, вероятно, не построили бы его на упрощенной абстракции потока символов. Таким образом, хотя truncate/extend в начале потенциально полезен для некоторых вещей (обрезка журналов вместо сегментированного вращения журнала, например), вряд ли это будет большая победа для большинства реализаций структуры данных.

Ответ 3

Ближайшим, который я видел, являются форматы файлов, которые указывают, что данные были "удалены", а затем удаленное пространство можно повторно использовать. Обычно это работает только с форматами записи фиксированной длины, такими как DBF, и требует немного больше памяти для поддержания как индексов удаленных записей для повторного использования, так и порядка записей в файле.

Ответ 4

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

Если ваша основная цель - просто сохранить дисковое пространство, существует несколько подходов.

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

В Linux вы также можете освобождать части хранилища файлов в файловой системе, поддерживающей разреженные файлы (большинство из них), используя системный вызов fallocate и передавая ему FALLOC_FL_PUNCH_HOLE. Solaris предоставляет аналогичную команду fcntl F_FREESP. Будут ли fallocate или fcntl работать эффективно или вообще зависит от реализации.

В качестве альтернативы, если вы запустите ОС, которая не предоставляет fallocate или эквивалентную функциональность, но поддерживает ZFS (например: FreeBSD) и/или если дедупликация не является опцией, потому что у вас недостаточно ОЗУ для ее выделения, легкая альтернатива просто будет включать сжатие в файловой системе.