Какой максимальный размер файла поддерживает unix v7

Обновлено: 29.06.2024

На прошлогодней выставке LinuxExpo компания SGI объявила о передаче своей технологии файловой системы с протоколированием XFS сообществу сторонников свободно распространяемых программ.

Данная файловая система долгое время оставалась одной из наиболее совершенных реализаций файловых систем для UNIX, решающих одну из основных проблем, ограничивавших распространение Linux в критически важных средах - отсутствие файловой системы с ведением журнала. Кроме того, XFS поддерживает все 64-разрядные функции для работы с файлами, что позволит масштабировать Linux для поддержки файловой системы, содержащей 18 млн. Тбайт данных и файлов размером до 9 млн. Тбайт. Данный шаг оказал существенное влияние на будущее Linux как платформы для приложений уровня предприятия. Любопытно посмотреть, как вообще в UNIX организована работа с большими файлами.

Файловая система XFS

Необходимость в масштабировании ОС и файловых систем возникла в конце 80-х, когда емкость дисков начала приближаться к 2 Гбайт - пределу существовавших тогда файловых систем и стало ясно, что в скором времени пользователям понадобятся новые системы, способные работать с большими файлами (таблица 1). Первыми на этот призыв откликнулись SGI и Digital Equipment, компании наиболее близко стоявшие тогда к корпоративным пользователям.

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

Масштабируемость. XFS может масштабироваться для удовлетворения требований к объему хранения и скорости операций ввода/вывода при доступе к памяти. Изначально XFS проектировалась для очень высоких уровней производительности, так что потоки свыше 300 Мбайт/с были продемонстрированы еще на системах CHALLENGE. Обычно, традиционные файлы, каталоги и файловые системы по мере роста обычно снижают производительность системы - файловая система XFS была спроектирована таким образом, что ее производительность не зависит от ее размера. Например, неизменная производительность была показана в тестах на XFS-каталогах емкостью до 32 миллионов файлов.

Поддержка больших файловых систем и больших файлов. XFS дает возможность управлять файловыми системами и отдельными файлами размером до 1 эксабайт (1018), то есть в миллионы раз больше, чем самые крупные из современных файловых систем. При этом обеспечивается совместимость с популярными 64-разрядными платформами. Например, версия от SGI сетевой файловой системы NFS 5.3 позволяет экспортировать 64-разрядные файловые системы в другие типы файловых систем. Можно использовать поставляемый с XFS интерфейс для работы с 32-разрядными программами, которые в результате могут работать с 64-разрядными позициями и размерами файлов. Используя комбинацию NFS и XFS можно плавно преодолеть ограничения 32-разрядных систем, а все существующее программное обеспечение будет работать без перекомпиляции с XFS-файлами размером до 2 Гбайт. Однако, для работы с файлами большего размера могут потребоваться некоторые изменения.

XFS позволяет создавать файловые системы с размером блока от 512 байт до 1 Мбайт. Пользователь может задавать конфигурацию экстентов (непрерывных данных) файла в момент его создания, за счет чего обеспечивается непрерывность записи данных на диск и увеличение скорости операций ввода/вывода. Как результат, нет задержек при доступе данных за счет перехода от одного экстента файла к другому. Максимальный размер одного экстента может достигать 1 Тбайт.

Управление большими каталогами с большим числом файлов. По мере роста размеров файловых систем, старый способ поиска файлов, предусматривающий линейный перебор, выполняется настолько медленно, что оказывается практически бесполезным. Для решения этой задачи в XFS включены большие каталоги, позволяющие динамически резервировать индексное пространство для файлов.

Программа управления томами XFS (менеджер XLV) является надстройкой над программой-менеджером логических томов и поддерживает стандартный набор операций для дискового массива RAID (striping, concatenation, mirroring). XLV «умеет» поддерживать «зеркальное» отображение корневого раздела (root partition). Кроме этого, XLV поддерживает «на лету» динамические изменения параметров томов, включая изменения размера монтированной файловой системы. XLV может использовать разделы диска для хранения разных типов файловых систем (XFS и EFS), а утилиты обеспечивают конвертирование логических томов без необходимости операций дампирования и восстановления данных.

Производительность на операциях ввода/вывода. Современные серверы используют большие распределенные дисковые массивы, способные обеспечивать совокупную полосу пропускания в сотни мегабайт в секунду. Ключевым моментом оптимизации производительности при работе с такими массивами становится требуемая мощность систем ввода/вывода и требуемая степень параллелизма операций ввода/вывода. Система XFS обеспечивает «гарантированную скорость операций ввода/вывода, что позволяет приложениям резервировать заданную пропускную способность файловой системы на ввод или вывод данных. Файловая система может определять наличную «пропускную способность» и гарантировать, что запрошенный уровень производительности может быть достигнут в заданное время. Это освобождает программистов от необходимости предсказывать производительность проектируемой системы, что особенно важно для таких систем, как пересылка видео по запросу или ввод данных.

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

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

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

Сегодня просто необходимо реализовать в Linux файловую технологию, позволяющую реализовывать корпоративные решения по хранению информации. Например, компания Caldera Systems постоянно получает от корпоративных потребителей запросы на подобные решения, особенно от компаний, работающих с графикой. Можно предположить, что подобное «вливание» в Linux значительно ускорит продвижение этой операционной системы на рынок больших корпоративных систем. По крайней мере, SGI сильно на это рассчитывает, если судить по тому, что в фирменных учебных центрах число предлагаемых курсов по Linux уже близко к числу курсов по собственной операционной системе IRIX.

Конкретная жизнь больших файлов на примере UnixWare

Сегодня считается дурным тоном не поддерживать в операционной системе работу с большими файлами, поэтому в описаниях Solaris, AIX и HP-UX также можно встретить указания на то, что эти системы работают с файлами до 1 Тбайт. Например, основная новая черта SCO UnixWare 7 - поддержка файлов размером почти 1 Тбайт (максимальный размер самой файловой системы установлен также на уровне 1 Тбайт).

Работа с большими файлами UnixWare возможна только в файловой системе vxfs, включаемой в момент создания файловой системы по команде

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

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

Если вы не использовали команду mkfs с флагом «о» или хотите модифицировать файловую систему позднее (система в этот момент должна быть размонтирована), используйте, например, команду:

Установив в системе параметр «largefiles», можно приступать к работе с большими файлами. Для этого можно воспользоваться специальным API-интерфейсом, не забыв включить соответствующие описания в тексты программ. Чтобы найти функции, не имеющие соответствующих деклараций, можно скомпилировать программу с флагом «-v»:

Если все декларации сделаны правильно, надо скомпилировать приложение с опцией, позволяющей переопределить некоторые функции ввода/вывода для работы с 64-разрядным интерфейсом вместо 32-разрядного, используемого по умолчанию:

Следует отметить, что дескрипторы файлов (например, stdin, stderr и stdout), наследуемые из родительских процессов, должны быть открыты для работы с большими файлами.

При разработке приложений с поддержкой больших файлов важно избежать некоторых потенциальных ловушек. Например, если в исходном коде используется описание смещений адресов (offset) как переменных целочисленного типа (int), то эти переменные могут «переполниться» при работе с 64-разрядными адресами.

Другие, менее очевидные, ограничения могут возникать при работе со следующими конструкциями:

Результатом операции (l

Таблица 1. Развитие файловых систем UNIX

Годы	Файловая система
Начало 70-х	Файловая система Version 7
Начало 1980-х	"Быстрая" файловая система FFS (Berkeley)
Середина 80-х	Ранние журнальные файловые системы (Veritas/Tolerant/IBM JFS)
Середина 90-х	XFS

Самый простой способ сгенерировать большой файл в UnixWare

Имеются специальные программы для генерации файлов любого размера:
/dev/zero - генерирует файл, содержащий одни нули.
/dev/byte/hex/ff - генерирует файл, содержащий одни единицы.
Для создания файла используется команда:
dd if=/dev/ of=// bs=1024k count=
где
- имя одной из перечисленных программ генерации файлов.
// - имя создаваемого файла.
- размер файла в мегабайтах.
Например, 250-мегабайтный файл из одних единиц с именем bigfile.ff может быть создан по команде:
dd if=/dev/byte/hex/ff of=/tmp/bigfile.ff
bs=1024k count=250

Спецификация файловой системы XFS

Технология поддержки файловой системы - журнальная 64-разрядная.

Максимальный размер файла - 9,223,372,036,854, 775,807 байт (9 млн. Тбайт).

Максимальный размер файловой системы - 18 млн. Тбайт.

Размер блока - выбирается в момент создания файловой системы (с помощью команды mkfs_512) и может составлять от 512 до 64 Кбайт для обычных данных и до 1 Мбайт для данных в системах реального времени. Экстенты файловой системы могут конфигурироваться во время создания файла и кратны размеру блока файловой системы. Размер физического сектора на диске поддерживается с учетом совместимости с 512-байтными секторами NFS. 64-разрядные файловые системы могут быть экспортированы в другие системы, поддерживающие протокол NFS V3. Системы с протоколом NFS V2 могут получать доступ к XFS-файлам внутри 32-разрядных ограничений поддерживаемого протокола.

Резервное копирование/восстановление - утилиты Dump/restore, bru, cpio, tar; IRIS NetWorker для IRIX.

Совместимость дампов - можно восстанавливать как дампы XFS, так и дампы EFS с преобразованием типа файловой системы. Может быть создан дамп активной файловой системы XFS с учетом произошедших в ней изменений в процессе создания резервной копии. Поддерживается параллельное выполнение операций создания резервных копий и восстановления.

Поддержка иерархической памяти - интерфейс DMIG (Data Management API) позволяет применять программное обеспечение управления иерархическими системами хранения данных без модификации ядра системы.

Файлы подкачки (Swap) - поддерживаются.

Гарантированная скорость операций ввода/вывода - на аппаратном (при отключении самодиагностики дисков) и программном уровнях.

Производительность - более высокая по сравнению с EFS (свыше 500 Мбайт/с).

Дополнительные возможности - XFS обеспечивает гарантированную скорость операций ввода/вывода для четырех потоков и выше.

Файлы небольшого объема могут размещаться непосредственно в информационных узлах (inode), не занимая дополнительного пространства на диске.

Команды XFS:

xfs_estimate - оценка объема дискового пространства, необходимого для размещения файловой системы XFS, в которую требуется преобразовать существующую файловую систему EFS;
mkfs, mkfs_xfs - создание файловой системы XFS;
xfs_check - проверка состояния файловой системы XFS;
xfs_growfs - расширение существующей файловой системы XFS;
xfsdump - дампирование файловой системы;
xfsrestore восстановление файловой системы из дампа.

Файл-менеджер логических томов XLV

Поддерживаемая топология - запись с чередованием (stripping), зеркальное дублирование (mirroring), слияние физических томов (concatenation). Каждый том может состоять из трех подтомов: тома реального времени, тома журнала, тома данных. Для обеспечения максимальной производительности журнал файловой системы может храниться в одном разделе (partition), а сама файловая система XFS - в другом.

Максимальное число дисков на файловую систему - каждый том может иметь до четырех независимых зеркальных копий, при записи с чередованиями для обеспечения наивысшей производительности может использоваться до 128 томов, можно объединять в один логический том до 128 томов-экстентов. Другие ограничения могут быть обусловлены аппаратными возможностями оборудования.

Корневой раздел (root partition) может также иметь зеркальную копию. Запись с чередованием и объединение томов для ранних реализаций XLV не поддерживаются. Для раздела /usr и всех других, кроме корневого, такого ограничения нет.

Динамическое изменение - добавление или удаление зеркальной копии, увеличение размера тома, замена сбойного сегмента на зеркальной копии.

Специфика XLV - зеркальные копии томов, запись с чередованием и логическое объединение томов поддерживаются базовым программным обеспечением.

Хотя это старая файловая система основные элементы используются и современных UNIX системах.

Имена файлов ограничены 14 символами ASCII, кроме косой черты "/" и NUL - отсутствие символа. (в последующих версиях расширены до 255)

Контроль доступа к файлам и каталогам.

Имена чувствительны к регистру, my.txt и MY.TXT это разные файлы.

Используется схема i-узлов.

Не делается различий между разными файлами (текстовыми, двоичными и д.р.).

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

Поддерживаются блочные специальные файлы (для блочных устройств ввода-вывода, например /dev/hd1).

Позволяет монтировать разделы в любое место дерева системы.

Расположение файловой системы UNIX

Количество дисковых блоков

Начало списка свободных блоков диска

При уничтожении суперблока, файловая система становится не читаемой.

Каждый i-узел имеет 64 байта в длину и описывает один файл (в том числе каталог).

Каталог содержит по одной записи для каждого файла.

Каталоговая запись UNIX V7 в 16 байт

Первые 10 дисковых блоков файла хранятся в самом i-узле, при блоке в 1Кбайт, файл может быть 10Кбайт.

Дополнительные блоки для i-узла, в случае больших файлов:

Одинарный косвенный блок - дополнительный блок с адресами блоков файла, если файл не сильно большой, то один из адресов в i-узле указывает на дополнительный блок с адресами. Файл может быть 266Кбайт=10Кбайт+256Кбайт (256Кбайт <= 256 (2^8)-адресов блоков = 1Кбайт-размер блока / 4байта-размер адреса)

Двойной косвенный блок - дополнительный блок с адресами одинарных косвенных блоков, если одного дополнительного блока не хватает. Файл может быть 65Мбайт=10Кбайт+2^8Кбайт+2^16Кбайт.

Тройной косвенный блок - дополнительный блок с адресами двойных косвенных блоков, если одного одинарного косвенного блока не хватает. Файл может быть 16Гбайт=10Кбайт+2^8Кбайт+2^16Кбайт+2^24Кбайт.

3.1.1 Поиск файла

Этапы поиска файла по абсолютному пути /usr/sbin/mc

При использовании относительного пути, например sbin/mc, поиск начинается с рабочего каталога /usr.

3.1.2 Блокировка данных файла

Блокирование осуществляется по блочно.

Стандартом POSIX два типа блокировки:

Блокировка с монополизацией - больше ни один процесс эти блоки заблокировать не может.

Блокировка без монополизации - могут блокировать и другие процессы.

Блокировки данных файла без монополизации

Если процесс К попытается блокировать блок 6 с монополизацией, то сам процесс будет заблокирован до разблокирования блока 6 всеми процессами.

3.1.3 Создание и работа с файлом

fd=creat("abc", mode) - Пример создания файла abc с режимом защиты, указанном в переменной mode (какие пользователи имеют доступ). Используется системный вызов creat.

Успешный вызов возвращает целое число fd - дескриптор файла.

Который хранится в таблице дескрипторов файла, открывшего процесса.

После этого можно работать с файлом, используя системные вызовы write и read.

n=read(fd, buffer, nbytes)

n=write(fd, buffer, nbytes)

У обоих вызовов всего по три параметра:

fd - дескриптор файла, указывающий на открытый файл

buffer - адрес буфера, куда писать или откуда читать данные

nbytes - счетчик байтов, сколько прочитать или записать байт

Теперь нужно по дескриптору получить указатель на i-узел и указатель на позицию в файле для записи или чтения.

Таблица открытых файлов - создана для хранения указателей на i-узел и на позицию в файле. И позволяет родительскому и дочернему процессам совместно использовать один указатель в файле, но для посторонних процессов выделять отдельные указатели.

Связь между таблицей дескрипторов файлов, таблицей открытых файлов и таблицей i-узлов.

3.2 Файловая система BSD

Основу составляет классическая файловая система UNIX.

Особенности (отличие от предыдущей системы):

Увеличена длина имени файла до 255 символов

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

Применено разбиение диска на группы цилиндров, чтобы i-узлы и блоки данных были поближе друг к другу, для каждой группы были свои:
- суперблок
- i-узлы
- блоки данных.
Это сделано для уменьшения перемещений галовок.

Используются блоки двух размеров, для больших файлов использовались большие блоки, для маленьких маленькие.

Каталоговые записи ни как не отсортированы и следуют друг за другом.

Каталог BSD с тремя каталоговыми записями для трех файлов и тот же каталог после удаления файла zip, увеличивается длина первой записи.

3.3 Файловые системы LINUX

Изначально использовалась файловая система MINIX с ограничениями: 14 символов для имени файла и размер файла 64 Мбайта.

После была создана файловая система EXT с расширением: 255 символов для имени файла и размер файла 2Гбайта.

Система была достаточно медленной.

3.3.1 Файловая система EXT2

Эта файловая система стала основой для LINUX, она очень похожа BSD систему.

Вместо групп цилиндров используются группы блоков.

Размещение файловой системы EXT2 на диске

Размер блока 1 Кбайт

Размер каждого i-узла 128 байт.

i-узел содержит 12 прямых и 3 косвенных адресов, длина адреса в i-узле стала 4 байта, что обеспечивает поддержку размера файла чуть более 16Гбайт.

Особенности работы файловой системы:

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

Новые файлы старается создавать в группе, где и находится каталог.

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

Благодаря этому файловую систему не нужно дефрагментировать, она не способствует фрагментации файлов (в отличии от NTFS), что проверено многолетним использованием.

3.3.2 Файловая система EXT3

В отличие от EXT2, EXT3 является журналируемой файловой системой, т.е. не попадет в противоречивое состояние после сбоев. Но она полностью совместима с EXT2.

Разработанная в Red Hat

В данный момент является основной для LINUX.

Драйвер Ext3 хранит полные точные копии модифицируемых блоков (1КБ, 2КБ или 4КБ) в памяти до завершения операции. Это может показаться расточительным. Полные блоки содержат не только изменившиеся данные, но и не модифицированные.

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

Типы журналирования поддерживаемые Ext3, которые могут быть активированы из файла /etc/fstab:

data=journal (full data journaling mode) - все новые данные сначала пишутся в журнал и только после этого переносятся на свое постоянное место. В случае аварийного отказа журнал можно повторно перечитать, приведя данные и метаданные в непротиворечивое состояние.
Самый медленный, но самый надежный.

data=ordered - записываются изменения только мета-данных файловой системы, но логически metadata и data блоки группируются в единый модуль, называемый transaction. Перед записью новых метаданных на диск, связанные data блоки записываются первыми. Этот режим журналирования ext3 установлен по умолчанию.
При добавлении данных в конец файла режим data=ordered гарантированно обеспечивает целостность (как при full data journaling mode). Однако если данные в файл пишутся поверх существующих, то есть вероятность перемешивания "оригинальных" блоков с модифицированными. Это результат того, что data=ordered не отслеживает записи, при которых новый блок ложится поверх существующего и не вызывает модификации метаданных.

data=writeback (metadata only) - записываются только изменения мета-данных файловой системы. Самый быстрый метод журналирования. С подобным видом журналирования вы имеете дело в файловых системах XFS, JFS и ReiserFS.

3.3.3 Файловая система XFS

XFS - журналируемая файловая система разработанная Silicon Graphics, но сейчас выпущенная открытым кодом (open source).

XFS была создана в начале 90ых (1992-1993) фирмой Silicon Grapgics (сейчас SGI) для мультимедийных компьютеров с ОС Irix. Файловая система была ориентирована на очень большие файлы и файловые системы. Особенностью этой файловой системы является устройство журнала - в журнал пишется часть метаданных самой файловой системы таким образом, что весь процесс восстановления сводится к копированию этих данных из журнала в файловую систему. Размер журнала задается при создании системы, он должен быть не меньше 32 мегабайт; а больше и не надо - такое количество незакрытых транзакций тяжело получить.

Более эффективно работает с большими файлами.

Имеет возможность выноса журнала на другой диск, для повышения производительности.

Сохраняет данные кэша только при переполнении памяти, а не периодически как остальные.

В журнал записываются только мета-данные.

Используются B+ trees.

Используется логическое журналирование

3.3.4 Файловая система RFS

RFS (RaiserFS) - журналируемая файловая система разработанная Namesys.

Официальная информация на RaiserFS

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

Использует специально оптимизированные b* balanced tree (усовершенствованная версия B+ дерева)

Динамически ассигнует i-узлы вместо их статического набора, образующегося при создании "традиционной" файловой системы.

Динамические размеры блоков.

3.3.4 Файловая система JFS

JFS (Journaled File System) - журналируемая файловая система разработанная IBM для ОС AIX, но сейчас выпущенная как открытый код.

Журналы JFS соответствуют классической модели транзакций, принятой в базах данных

В журнал записываются только мета-данные

Размер журнала не больше 32 мегабайт.

Асинхронный режим записи в журнал - производится в моменты уменьшения трафика ввода/вывода

Что такое файловая система

Полезные данные, такие как файлы и каталоги, напрямую на диск не записываются. Между разделом диска и файлами существует прослойка в виде файловой системы.

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

дата его создания;
пользователь создавший этот файл;
тип файла;
права доступа к этому файлу;
и подобная информация о файле.

Разные файловые системы имеют разные ограничения, например:

максимальный размер раздела;
наибольший размер файла;
максимальная длина имени файла.

В этой статье пробежимся по файловым системам, которые можно выбрать при установки Debian 10 и Ubuntu 20.04. При установке Debian 10 вы можете выбрать следующие файловые системы:

Установщик Ubuntu 20.04 имеет несколько меньший выбор:

Далее пробежимся по этим файловым системам:

Файловые системы семейства ext

EXT (Extended File System) — расширенная файловая система.

Ext2 была создана в январе 1993 года для linux, вот её особенности:

Ext2 старая файловая система без журнала, но достаточно быстрая. Современные системы Linux могут работать с этой файловой системой.

Ext4 была создана в октябре 2006 года, но стабильная версия появилось в октябре 2008 года. Она сейчас является самой распространенной файловой системой для Linux. Убрали некоторые ограничения и оптимизировали:

На данный момент по моему мнению EXT4 лучший выбор для Linux систем.

btrfs

снимки состояния, которые позволяют запомнить состояние на определенный момент времени всех файлов и вернуться к этому состоянию в последующем. Полезно когда вы случайно удалили что-то важное или какой-то вирус зашифровал все ваши данные на компьютере;
создание RAID конфигурации на уровне файловой системы;
сжатие данных, когда данные при создании автоматически сжимаются экономя свободное место на диске;
дедупликация данных. Когда есть два или более одинаковых файла, то они занимают размер только одного файла, что очень экономит пространство на жестком диске;
контрольные суммы для данных и метаданных, что повышает надежность файловой системы;
дефрагментация данных на лету;
квоты на разделы;
динамическая аллокация inode;
максимальный размер файла 16 EB;
наибольший размер раздела 16 EB;
максимальный размер имени файла 255 B;

Из минусов: файловая система не так проверена временем как ext4, активно использует оперативную память и работает медленнее чем ext4.

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

Вот некоторые её особенности:

максимальная длина имени файла 255 B;
максимальный размер файла 4 PB (4000 TB);
максимальный размер раздела 32 PB (32000 TB);
контрольные суммы;
поддержка acl.

Так как по функциональности эта файловая система сравнима с ext4, но по характеристикам и популярности отстаёт, то в Ubintu установщик уже не предлагает использовать её. Можно использовать, если у вас будут храниться файлы размером более 16 ТБ, хотя и в этом случае лучше выбрать XFS.

максимальная длина имени файла 255 B;
наибольший размер файла 9 EB;
максимальный размер раздела 9 EB;
автоматическая аллокация и высвобождение inode;
дефрагментация «на лету»;

низкая производительность при работе с большим количеством файлов;
невозможность уменьшить размер существующей файловой системы.

Эта файловая система позволит хранить просто огромные файлы, размер которых может достигать 9 EB.

Файловые системы семейства fat

fat16 — максимальный раздел 2 GB, в настоящее время потеряла свою актуальность;
fat32 — максимальный раздел 2 TB, для работы приложений не подходит, максимум можно использовать для хранения информации на флеш накопителе.

В настоящее время рекомендуется использовать ext4 для работы Linux систем, а если вам нужны дополнительные функции можно изучить и использовать btrfs, если планируете хранить крупные файлы то можно попробовать xfs.
Также если вам важнее скорость чем надежность можно использовать ext2, так как в ней нет журнала она должна работать быстрее чем ext4.
Ну а fat32 можно использовать для хранения информации на флеш накопителе.

Кроме перечисленных файловых систем Linux может работать и с другими, например ntfs или zfs. Но так как их нельзя выбирать при установке, они были опущены. На этом сайте я планирую познакомить вас с файловой системой zfs, так как имею большой опыт работы с ней, но не в этом курсе, а в отдельных статьях.

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

Позже в Unix- системах использовалась быстрая файловая система Беркли ( BSD Fast File System , FFS ), которая отличается от UFS.

Содержание

Дизайн

Том UFS состоит из следующих частей:

Несколько блоков в начале раздела зарезервированы для загрузочных блоков (которые должны быть инициализированы отдельно от файловой системы)
Суперблок, содержащий магическое число, идентифицирующее это как файловую систему UFS, и некоторые другие важные числа, описывающие геометрию и статистику этой файловой системы, а также параметры настройки поведения.
Набор групп цилиндров. Каждая группа цилиндров состоит из следующих компонентов:
- Резервная копия суперблока
- Заголовок группы цилиндров со статистикой, списками свободных номеров и т. Д., Относящимися к этой группе цилиндров, как и в суперблоке
- Количество inodes , каждый из которых содержит атрибуты файла
- Ряд блоков данных
Inodes нумеруются последовательно, начиная с 0. Inode 0 зарезервирован для нераспределенных записей каталога, inode 1 был inode файла плохого блока в исторических версиях UNIX, за ним идёт inode для корневого каталога , который всегда inode 2 и inode. для каталога lost + found, который является индексом 3.

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

История и эволюция

Ранние версии файловых систем Unix назывались просто FS . FS включала только загрузочный блок, суперблок, группу inodes и блоки данных. Это хорошо работало для небольших дисков, для которых были разработаны ранние Unix, но по мере развития технологий и увеличения размеров дисков перемещение головки вперед и назад между скоплением inodes и блоками данных, на которые они ссылались, вызывало перегрузку . Маршалл Кирк МакКусик , в то время аспирант в Беркли , оптимизировал FFS (Fast File System) BSD 4.2 , придумав группы цилиндров, которые разбивают диск на более мелкие части, причем каждая группа имеет свои собственные индексы и блоки данных.

Цель BSD FFS - попытаться локализовать связанные блоки данных и метаданные в одной группе цилиндров и, в идеале, все содержимое каталога (как данные, так и метаданные для всех файлов) в той же или соседней группе цилиндров, таким образом уменьшение фрагментации, вызванной разбросом содержимого каталога по всему диску.

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

По мере того, как диски становились все больше и больше, оптимизация на уровне секторов стала устаревшей (особенно с дисками, которые использовали линейную нумерацию секторов и переменные сектора на дорожку). С большими дисками и большими файлами фрагментированное чтение стало большей проблемой. Чтобы бороться с этим, BSD изначально увеличила размер блока файловой системы с одного сектора до 1 КБ в 4.0 BSD; а в FFS увеличил размер блока файловой системы с 1 КБ до 8 К. Это имеет несколько эффектов. Вероятность того, что секторы файла будут смежными, намного выше. Объем служебных данных для перечисления блоков файла уменьшается, в то время как количество байтов, представляемых любым заданным количеством блоков, увеличивается.

Также возможны диски большего размера, поскольку максимальное количество блоков ограничено фиксированным числом блоков разрядности. Однако при больших размерах блоков диски с большим количеством мелких файлов будут тратить впустую пространство, поскольку каждый файл должен занимать хотя бы один блок. Из-за этого в BSD добавлена фрагментация на уровне блоков , также называемая перераспределением блоков, слиянием хвостов или упаковкой хвостов , когда последний частичный блок данных из нескольких файлов может храниться в одном блоке «фрагмента» вместо нескольких, по большей части, пустых блоков ( Аллен 2005 ).

Реализации

Поставщики некоторых проприетарных систем Unix, таких как SunOS / Solaris , System V Release 4 , HP-UX и Tru64 UNIX , а также открытых систем, производных от Unix, таких как illumos , приняли UFS. Большинство из них адаптировали UFS для собственных нужд, добавив проприетарные расширения, которые могут не распознаваться версиями Unix других поставщиков. Многие продолжают использовать исходный размер блока и ширину полей данных в качестве исходной UFS, поэтому некоторая степень совместимости чтения остается на разных платформах. Совместимость между реализациями в целом в лучшем случае неоднородна.

Начиная с Solaris 7 , Sun Microsystems включала в себя ведение журнала UFS, которое принесло журналирование файловой системы в UFS, которое по-прежнему доступно в текущих версиях Solaris и illumos. Solaris UFS также имеет расширения для больших файлов и больших дисков и другие функции.

В системах Unix 4.4BSD и BSD, производных от него, таких как FreeBSD , NetBSD , OpenBSD и DragonFlyBSD , реализация UFS1 и UFS2 разделена на два уровня: верхний уровень, который обеспечивает структуру каталогов и поддерживает метаданные (разрешения, владение, и т. д.) в структуре индексных дескрипторов и нижние уровни, которые предоставляют контейнеры данных, реализованные как дескрипторы. Это было сделано для поддержки как традиционной FFS, так и файловой системы с журнальной структурой LFS с общим кодом для общих функций. Верхний уровень называется «UFS», а нижние уровни - «FFS» и «LFS». В некоторых из этих систем термин «FFS» используется для комбинации нижнего уровня FFS и верхнего уровня UFS, а термин «LFS» используется для комбинации нижнего уровня LFS и верхнего уровня UFS.

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

В UFS2 Кирк МакКусик и Пол-Хеннинг Камп расширили уровни FreeBSD FFS и UFS, добавив 64-битные указатели блоков (позволяющие увеличивать объемы до 8 зебибайт ), блоки переменного размера (аналогичные экстентам ), расширенные поля флагов, дополнительные Штампы «время рождения», поддержка расширенных атрибутов и ACL POSIX1.e. UFS2 стала версией UFS по умолчанию, начиная с FreeBSD 5.0. FreeBSD также представила программные обновления и возможность делать снимки файловой системы как для UFS1, так и для UFS2. С тех пор они были перенесены на NetBSD, но в конечном итоге мягкие обновления (называемые мягкими зависимостями в NetBSD) были удалены из NetBSD 6.0 в пользу менее сложного механизма журналирования файловой системы под названием WAPBL (также называемого журналированием), который был добавлен в FFS в NetBSD. 5.0. OpenBSD поддерживает программные обновления с версии 2.9 и поддерживает UFS2 (FFS2) (без ACL) с версии 4.2. OpenBSD сделал UFS2 версией UFS по умолчанию и будет включен в выпуск 6.7. Начиная с FreeBSD 7.0, UFS также поддерживает ведение журнала файловой системы с помощью поставщика gjournal GEOM . FreeBSD 9.0 добавляет поддержку легкого журналирования поверх мягких обновлений (SU + J), что значительно снижает потребность в фоновой fsck и списках ACL NFSv4.

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. В компании Apple «s Mac OS X , она была доступна в качестве альтернативы HFS + , их собственной файловой системы. Однако, начиная с Mac OS X Leopard , больше нельзя было установить Mac OS X на том в формате UFS. Кроме того, нельзя обновить старые версии Mac OS X, установленные на томах в формате UFS, до Leopard; обновление требует переформатирования загрузочного тома. Для дисков, отформатированных как UFS в Mac OS X, было ограничение в 4 ГБ. Начиная с Mac OS X Lion , поддержка UFS была полностью прекращена.

Читайте также: