Файловая система Unix ( UFS ) — это семейство файловых систем, поддерживаемых многими операционными системами Unix и Unix-подобными . Это дальний потомок исходной файловой системы, используемой в версии 7 Unix .
Том UFS состоит из следующих частей:
Иноды нумеруются последовательно, начиная с 0. Инод 0 зарезервирован для нераспределенных записей каталога, инод 1 был инодом файла плохого блока в исторических версиях UNIX, за ним следует инод для корневого каталога , который всегда является инодом 2, и инод для каталога lost+found, который является инодом 3.
Файлы каталога содержат только список имен файлов в каталоге и иноды, связанные с каждым файлом. Все метаданные файла хранятся в иноде.
Ранние файловые системы Unix назывались просто FS . FS включала только загрузочный блок, суперблок, группу инодов и блоки данных. Это хорошо работало для небольших дисков, для которых были разработаны ранние Unix, но по мере развития технологий и увеличения дисков перемещение головки вперед и назад между группой инодов и блоками данных, к которым они относились, вызывало перегрузки . Маршалл Кирк МакКьюсик , тогда аспирант Беркли , оптимизировал схему V7 FS для создания FFS (быстрой файловой системы) BSD 4.2 , придумав группы цилиндров, которые разбивают диск на более мелкие фрагменты, причем каждая группа имела свои собственные иноды и блоки данных. [2] [3]
Целью BSD FFS является попытка локализовать связанные блоки данных и метаданные в одной и той же группе цилиндров, а в идеале — все содержимое каталога (как данные, так и метаданные для всех файлов) в одной и той же или соседней группе цилиндров, тем самым уменьшая фрагментацию, вызванную разбросом содержимого каталога по всему диску.
Некоторые из параметров производительности в суперблоке включали количество дорожек и секторов, скорость вращения диска, скорость головки и выравнивание секторов между дорожками. В полностью оптимизированной системе головка могла перемещаться между близкими дорожками для считывания разбросанных секторов с чередующихся дорожек, ожидая, пока пластина обернется вокруг.
По мере того, как диски становились все больше и больше, оптимизация на уровне секторов становилась устаревшей (особенно для дисков, которые использовали линейную нумерацию секторов и переменные сектора на дорожку). С большими дисками и большими файлами фрагментированное чтение становилось все большей проблемой. Чтобы бороться с этим, BSD изначально увеличила размер блока файловой системы с одного сектора до 1 К в 4.0 BSD; а в FFS увеличила размер блока файловой системы с 1 К до 8 К. Это имеет несколько эффектов. Вероятность того, что секторы файла будут смежными, намного выше. Количество накладных расходов на перечисление блоков файла уменьшается, в то время как количество байтов, представляемых любым заданным числом блоков, увеличивается.
Большие размеры дисков также возможны, поскольку максимальное количество блоков ограничено фиксированным номером блока битовой ширины. Однако при больших размерах блоков диски с большим количеством маленьких файлов будут тратить место впустую, поскольку каждый файл должен занимать по крайней мере один блок. Из-за этого BSD добавила фрагментацию на уровне блоков , также называемую подвыделением блоков, слиянием хвостов или упаковкой хвостов , где последний частичный блок данных из нескольких файлов может храниться в одном блоке «фрагмента» вместо нескольких в основном пустых блоков. [4]
Работа над Berkeley FFS была широко принята другими поставщиками Unix, а семейство файловых систем, созданных на ее основе, известно под общим названием UFS.
Поставщики некоторых фирменных систем Unix, таких как SunOS / Solaris , System V Release 4 , HP-UX и Tru64 UNIX , а также открытых производных систем Unix, таких как illumos , приняли UFS. Большинство из них адаптировали UFS для собственных нужд, добавив фирменные расширения, которые могут не распознаваться версиями Unix других поставщиков. Многие [ which? ] продолжили использовать исходный размер блока и ширину полей данных как в исходной UFS, поэтому некоторая степень совместимости по чтению сохраняется между платформами. [ which? ] [ необходима цитата ] [ по мнению кого? ] Совместимость между реализациями в целом в лучшем случае неоднородна. [ по мнению кого? ]
Начиная с Solaris 7 , Sun Microsystems включила UFS Logging, что позволило реализовать журналирование файловой системы в UFS, которое по-прежнему доступно в текущих версиях Solaris и illumos. [5] Solaris UFS также имеет расширения для больших файлов и больших дисков, а также другие функции.
В системах 4.4BSD и BSD Unix, производных от нее, таких как FreeBSD , NetBSD , OpenBSD и DragonFlyBSD , реализация UFS1 и UFS2 разделена на два уровня: верхний уровень, который обеспечивает структуру каталогов и поддерживает метаданные (разрешения, владение и т. д.) в структуре inode, и нижние уровни, которые предоставляют контейнеры данных, реализованные как inode. Это было сделано для поддержки как традиционной FFS, так и файловой системы с лог-структурой LFS с общим кодом для общих функций. Верхний уровень называется «UFS», а нижние уровни называются «FFS» и «LFS». В некоторых из этих систем термин «FFS» используется для комбинации нижнего уровня FFS и верхнего уровня UFS, а термин «LFS» используется для комбинации нижнего уровня LFS и верхнего уровня UFS.
Кирк МакКьюсик реализовал перераспределение блоков, технику, которая переупорядочивает блоки в файловой системе непосредственно перед записью, чтобы уменьшить фрагментацию и контролировать старение файловой системы. Он также реализовал мягкие обновления , механизм, который поддерживает согласованность файловой системы, не ограничивая производительность так, как это делал традиционный режим синхронизации. Это имеет побочный эффект в виде снижения необходимости проверки файловой системы после сбоя или отключения питания. Чтобы преодолеть оставшиеся проблемы после сбоя, была введена фоновая утилита fsck.
В UFS2 Кирк МакКусик и Пол-Хеннинг Камп расширили уровни FreeBSD FFS и UFS, добавив 64-битные указатели блоков (позволяющие томам увеличиваться до 8 зебибайт ), блоки переменного размера (похожие на экстенты ), расширенные поля флагов, дополнительные отметки «времени рождения», расширенную поддержку атрибутов и списки контроля доступа POSIX1.e. UFS2 стала поддерживаемой версией UFS, начиная с FreeBSD 5.0. FreeBSD также представила мягкие обновления и возможность делать снимки файловой системы как для UFS1, так и для UFS2. С тех пор они были перенесены в NetBSD, но в конечном итоге мягкие обновления (называемые мягкими зависимостями в NetBSD) были удалены из NetBSD 6.0 в пользу менее сложного механизма журналирования файловой системы, называемого WAPBL (также называемого журналированием), который был добавлен в FFS в NetBSD 5.0. OpenBSD поддерживает мягкие обновления с версии 2.9 [6] и имеет поддержку UFS2 (FFS2) (без ACL) с версии 4.2. [7] OpenBSD теперь сделала UFS2 версией UFS по умолчанию и будет включена в выпуск 6.7. [8] Начиная с FreeBSD 7.0, UFS также поддерживает журналирование файловой системы с использованием поставщика GEOM gjournal . FreeBSD 9.0 добавляет поддержку легкого журналирования поверх мягких обновлений (SU+J), что значительно снижает необходимость в фоновом fsck и NFSv4 ACL.
FreeBSD, NetBSD, OpenBSD и DragonFly BSD также включают систему Dirhash , разработанную Яном Доузом. Эта система поддерживает хэш-таблицу в памяти для ускорения поиска каталогов. Dirhash устраняет ряд проблем производительности, связанных с большими каталогами в UFS.
Linux включает реализацию UFS для двоичной совместимости на уровне чтения с другими Unix, но поскольку нет стандартной реализации для расширений поставщика для UFS, Linux не имеет полной поддержки записи в UFS. Собственная файловая система Linux ext2 была вдохновлена UFS1, но не поддерживает фрагменты, и нет никаких планов по внедрению мягких обновлений. [ необходима цитата ] (В некоторых системах, производных от 4.4BSD, уровень UFS может использовать уровень ext2 в качестве уровня контейнера, так же как он может использовать FFS и LFS.)
NeXTStep , которая была производной от BSD, также использовала версию UFS. В Mac OS X от Apple она была доступна как альтернатива HFS+ , их фирменной файловой системе. Однако, начиная с Mac OS X Leopard , больше не было возможности установить Mac OS X на том, отформатированный в UFS. Кроме того, нельзя обновить старые версии Mac OS X, установленные на томах, отформатированных в UFS, до Leopard; обновление требует переформатирования загрузочного тома. [9] Существовало ограничение на размер файла в 4 ГБ для дисков, отформатированных как UFS в Mac OS X. Начиная с Mac OS X Lion , поддержка UFS была полностью прекращена. [10]
{{cite tech report}}: CS1 maint: несколько имен: список авторов ( ссылка ){{cite journal}}: CS1 maint: multiple names: authors list (link)