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

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

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

Файловые системы также могут поддерживать обратную вставку, то есть удаление диапазона байтов в середине файла.

И замена диапазона байтов другим, даже если размер отличается, что является комбинацией вставки и удаления.

Файловая система также должна стать более эффективной при обработке крошечных файлов, чтобы ее можно было использовать вместо базы данных. Это не должно занимать намного больше места, чем кодирование их всех в SQL, JSON или какой-либо другой формат. И это не должно быть медленнее для доступа или изменения.

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

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

Одним из них является контрольная сумма данных для защиты от повреждения. Они должны быть криптографически безопасными. Не MD5, например [2]. Если файловая система вычисляет контрольные суммы данных, у форматов файлов будет меньше причин для этого.

Файловая система также должна прозрачно сжимать данные. Это важно в мире с твердотельными накопителями на 128 ГБ, даже на Macbook Air за тысячу долларов. Разработчикам приложений не нужно заново изобретать это для каждого приложения, а пользователям не должно не хватать места, если это легко предотвратить с помощью технологии 20-летней давности [3].

Кроме того, есть поисковый API, так что приложения могут легко индексировать свои данные и выполнять поиск не только конечными пользователями, но и самим приложением. Такое приложение, как Lightroom, которое позволяет фильтровать вашу библиотеку по типу файла, может использовать для этого запрос Spotlight вместо того, чтобы заново реализовывать то, что предоставляет ОС.

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

Файловая система также может поддерживать историю изменений файлов и папок не только в пользовательском интерфейсе, таком как Машина времени, но и через API для использования приложениями. Затем приложение для заметок, такое как Simplenote, которое позволяет пользователям просматривать историю изменений заметок, может просто вызывать API ОС, а не реализовывать его заново.

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

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

[1] Даже если реализация файловой системы в конечном итоге копирует данные, она, вероятно, может сделать это более оптимизированным способом, чем код приложения. Например, в C, а не в управляемом коде. Или копирование единиц измерения быстрее, будь то байты, 16-битные, 32-битные или 64-битные. Или с помощью API, такого как sendfile. В целом, поскольку код файловой системы будет использоваться миллионами приложений, мы можем потратить гораздо больше времени на его оптимизацию.

[2] Это означает, что следующая версия файловой системы должна иметь возможность переключаться на лучшую контрольную сумму, если текущая версия окажется небезопасной. Путь обновления должен быть разработан с первого дня.

[3] Алгоритмы сжатия для конкретной предметной области, такие как аудио и видео, по-прежнему имеют значение. Файловая система должна попытаться сжать первый КБ или около того каждого файла, и если она не сжимается, сдаться. Таким образом, разработчикам приложений не придется беспокоиться о втором алгоритме сжатия, вызывающем расширение или замедление записи.

[4] Вилки и расширенные атрибуты выполняют одну и ту же цель.