Файловые системы компьютеров: организация и доступ к данным

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

33 мин чтения

100%

Источник: File system — Wikipedia

Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.

Содержание

Введение

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

В вычислительной технике файловая система (часто сокращаемая до FS или fs) управляет организацией и доступом к файлам. Локальная файловая система – это функция операционной системы, обслуживающая приложения, работающие на том же компьютере. Распределенная файловая система – это протокол, обеспечивающий доступ к файлам между компьютерами в сети. Файловая система предоставляет сервис хранения данных, позволяющий приложениям совместно использовать ресурсы памяти. Без файловой системы приложения могли бы обращаться к памяти несовместимыми способами, что привело бы к конфликтам ресурсов, повреждению и потере данных. Существует множество различных конструкций и реализаций файловых систем, отличающихся структурой, функциями и характеристиками, такими как скорость, гибкость, безопасность и объем. Файловые системы разработаны для различных типов устройств хранения, включая жесткие диски (HDD), твердотельные накопители (SSD), магнитные ленты и оптические диски. Часть основной памяти компьютера может быть настроена как RAM-диск, служащий устройством хранения для файловой системы. Файловые системы, такие как tmpfs, могут хранить файлы в виртуальной памяти. Виртуальная файловая система обеспечивает доступ к файлам, которые либо генерируются по запросу (виртуальные файлы, например, в procfs и sysfs), либо отображаются на другое, базовое хранилище.

Этимология

С начала 1900-х годов и до появления компьютеров термины "файловая система", "система хранения" и "система для хранения" использовались для описания методов организации, хранения и поиска бумажных документов. К 1961 году термин "файловая система" стал применяться и к компьютерному хранению данных, наряду с его первоначальным значением. К 1964 году он вошёл в широкое употребление.

Архитектура

Архитектура локальной файловой системы может быть описана как слои абстракции, даже если конкретная реализация файловой системы не разделяет эти концепции явно. Логический уровень файловой системы предоставляет относительно высокоуровневый доступ через интерфейс прикладного программирования (API) для файловых операций, таких как открытие, закрытие, чтение и запись, делегируя выполнение операций нижележащим уровням. Этот уровень управляет записями в таблице открытых файлов и файловыми дескрипторами процессов. Он обеспечивает доступ к файлам, операции с каталогами, а также безопасность и защиту данных. Нативные файловые системы Unix-подобных систем также поддерживают произвольные иерархии каталогов, как и иерархическая файловая система Apple и её преемник HFS+ в классической Mac OS, файловая система FAT в MS DOS 2.0 и последующих версиях MS DOS и Microsoft Windows, файловая система NTFS в семействе операционных систем Windows NT, а также ODS 2 (On Disk Structure 2) и более высокие уровни файловой системы Files 11 в OpenVMS.

Организация хранилищ

Локальная файловая система отслеживает, какие области хранения принадлежат каким файлам, а какие не используются. Когда файловая система создает файл, она выделяет место для данных. Некоторые файловые системы позволяют или требуют указания первоначального объема выделяемого пространства и последующего инкрементного выделения по мере роста файла. Для удаления файла файловая система отмечает пространство, занимаемое файлом, как свободное, то есть доступное для использования другим файлом. Локальная файловая система управляет пространством хранения для обеспечения определенного уровня надежности и эффективности. Обычно она выделяет пространство на устройстве хранения гранулярно, как правило, в виде нескольких физических единиц (то есть байтов). Например, в Apple DOS начала 1980-х годов 256-байтовые сектора на 140-килобайтной дискете использовали карту треков/секторов. Эта гранулярность приводит к неиспользованному пространству, иногда называемому "свободным местом" или "slack space", для каждого файла, за исключением тех, размер которых кратен размеру гранулы выделения. Для выделения в 512 байт средний объем неиспользованного пространства составляет 256 байт. Для кластеров объемом 64 КБ средний объем неиспользованного пространства составляет 32 КБ. Как правило, размер единицы выделения задается при настройке хранилища. Выбор относительно небольшого размера по сравнению с размером хранимых файлов приводит к избыточным накладным расходам на доступ. Выбор относительно большого размера приводит к избыточному неиспользованному пространству. Выбор размера выделения, основанного на среднем размере файлов, которые ожидаются в хранилище, обычно минимизирует объем неиспользуемого пространства.

Фрагментация

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

Контроль доступа

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

Хранение квоты

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

Доступ к потоку байтов

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

Доступ к записи

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

Коммунальные услуги

Как правило, файловой системой можно управлять через различные утилиты. Некоторые утилиты позволяют пользователю создавать, настраивать и удалять экземпляр файловой системы. Они могут позволять расширять или сокращать пространство, выделенное для файловой системы. Утилиты для работы с каталогами могут использоваться для создания, переименования и удаления записей каталогов, также известных как dentries (в единственном числе – dentry), и для изменения метаданных, связанных с каталогом. Утилиты для работы с каталогами могут также включать в себя возможности создания дополнительных ссылок на каталог (жесткие ссылки в Unix), переименования родительских ссылок (".." в Unix-подобных операционных системах) и создания двунаправленных ссылок на файлы. Файловые утилиты создают, перечисляют, копируют, перемещают и удаляют файлы, а также изменяют метаданные. Они могут быть способны усекать данные, сокращать или расширять выделение пространства, добавлять данные в конец файла, перемещать и изменять файлы непосредственно в месте их хранения. В зависимости от базовой структуры файловой системы, они могут предоставлять механизм для добавления данных в начало файла или усечения его начала, вставки записей в середину файла или удаления записей из файла. Утилиты для освобождения места, занимаемого удаленными файлами, если файловая система предоставляет функцию восстановления удаленных файлов, также относятся к этой категории. Некоторые файловые системы откладывают такие операции, как реорганизация свободного пространства, безопасное удаление свободного пространства и перестройка иерархических структур, предоставляя утилиты для выполнения этих функций в периоды минимальной активности. Примером служат утилиты дефрагментации файловой системы. К наиболее важным функциям утилит файловой системы относятся административные действия, которые могут включать в себя обход прав собственности или прямой доступ к базовому устройству. К ним относятся высокопроизводительное резервное копирование и восстановление, репликация данных и реорганизация различных структур данных и таблиц размещения в файловой системе.

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

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

Несколько файловых систем в одной системе

Часто розничные системы конфигурируются с использованием одной файловой системы, занимающей всё пространство накопителя. Другой подход заключается в разбиении диска на разделы, чтобы можно было использовать несколько файловых систем с различными атрибутами. Одна файловая система, предназначенная для использования в качестве кэша браузера или хранилища электронной почты, может быть настроена с небольшим размером выделения. Это позволяет ограничить операции создания и удаления файлов, характерные для работы браузера, узкой областью диска, где они не будут мешать другим выделениям файлов. Другой раздел может быть создан для хранения аудио- или видеофайлов с относительно большим размером блока. Ещё один раздел может быть установлен в режим «только для чтения» и периодически переводиться в режим записи. Некоторые файловые системы, такие как ZFS и APFS, поддерживают совместное использование общего пула свободных блоков несколькими файловыми системами с разными атрибутами, без необходимости резервирования фиксированного объёма места для каждой файловой системы. Третий подход, который в основном используется в облачных системах, заключается в использовании «образов дисков» для размещения дополнительных файловых систем, с одинаковыми или различными атрибутами, внутри другой (хост-) файловой системы в виде файла. Типичным примером является виртуализация: пользователь может запустить экспериментальный дистрибутив Linux (с использованием файловой системы ext4) в виртуальной машине в своей рабочей среде Windows (с использованием NTFS). Файловая система ext4 находится в образе диска, который рассматривается как файл (или несколько файлов, в зависимости от гипервизора и настроек) в хост-файловой системе NTFS. Наличие нескольких файловых систем в одной системе имеет дополнительное преимущество: в случае повреждения одной файловой системы остальные файловые системы часто остаются нетронутыми. Это включает в себя уничтожение системной файловой системы вирусами или даже ситуацию, когда система не загружается. Утилиты файловой системы, требующие эксклюзивного доступа, могут быть эффективно выполнены поэтапно. Кроме того, дефрагментация может быть более эффективной. Несколько утилит для обслуживания системы, таких как сканирование на вирусы и создание резервных копий, также могут обрабатываться сегментами. Например, нет необходимости создавать резервную копию файловой системы, содержащей видео, вместе со всеми остальными файлами, если с момента последней резервной копии ничего не было добавлено. Что касается файлов образов, то можно легко создавать дифференциальные образы, содержащие только «новые» данные, записанные в основной (исходный) образ. Дифференциальные образы могут использоваться как для обеспечения безопасности (поскольку «одноразовую» систему можно быстро восстановить в случае повреждения или заражения вирусом, удалив старый образ и создав новый образ за считанные секунды, даже без автоматизированных процедур), так и для быстрого развёртывания виртуальных машин (поскольку дифференциальные образы можно быстро создавать с помощью скрипта пакетами).

Frequently, retail systems are configured with a single file system occupying the entire storage device. Another approach is to partition the disk so that several file systems with different attributes can be used. One file system, for use as browser cache or email storage, might be configured with a small allocation size. This keeps the activity of creating and deleting files typical of browser activity in a narrow area of the disk where it will not interfere with other file allocations. Another partition might be created for the storage of audio or video files with a relatively large block size. Yet another may normally be set read only and only periodically be set writable. Some file systems, such as ZFS and APFS, support multiple file systems sharing a common pool of free blocks, supporting several file systems with different attributes without having to reserved a fixed amount of space for each file system. A third approach, which is mostly used in cloud systems, is to use "disk images" to house additional file systems, with the same attributes or not, within another (host) file system as a file. A common example is virtualization: one user can run an experimental Linux distribution (using the ext4 file system) in a virtual machine under his/her production Windows environment (using NTFS). The ext4 file system resides in a disk image, which is treated as a file (or multiple files, depending on the hypervisor and settings) in the NTFS host file system. Having multiple file systems on a single system has the additional benefit that in the event of a corruption of a single file system, the remaining file systems will frequently still be intact. This includes virus destruction of the system file system or even a system that will not boot. File system utilities which require dedicated access can be effectively completed piecemeal. In addition, defragmentation may be more effective. Several system maintenance utilities, such as virus scans and backups, can also be processed in segments. For example, it is not necessary to backup the file system containing videos along with all the other files if none have been added since the last backup. As for the image files, one can easily "spin off" differential images which contain only "new" data written to the master (original) image. Differential images can be used for both safety concerns (as a "disposable" system can be quickly restored if destroyed or contaminated by a virus, as the old image can be removed and a new image can be created in matter of seconds, even without automated procedures) and quick virtual machine deployment (since the differential images can be quickly spawned using a script in batches).

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

Дисковая файловая система использует возможность дисковых носителей быстрого произвольного доступа к данным. Дополнительные факторы включают скорость доступа к данным, следующим за первоначально запрошенными, и предвидение того, что последующие данные также могут потребоваться. Это обеспечивает доступ к различным данным на диске множеству пользователей (или процессов) независимо от их последовательного расположения. Примеры включают FAT (FAT12, FAT16, FAT32), exFAT, NTFS, ReFS, HFS и HFS+, HPFS, APFS, UFS, ext2, ext3, ext4, XFS, btrfs, Files 11, Veritas File System, VMFS, ZFS, ReiserFS, NSS и ScoutFS. Некоторые дисковые файловые системы являются файловыми системами с журналированием или файловыми системами с версионированием.

Оптические диски

ISO 9660 и Universal Disk Format (UDF) — два распространенных формата, предназначенных для компакт-дисков, DVD и Blu-ray дисков. Mount Rainier — расширение UDF, поддерживаемое начиная с версии 2.6 ядра Linux и Windows Vista, которое упрощает перезапись DVD-дисков.

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

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

Системы кассетных файлов

Файловая система для ленты – это файловая система и формат ленты, предназначенные для хранения файлов на магнитной ленте. Магнитные ленты являются носителями последовательного доступа, характеризующимися значительно большим временем произвольного доступа к данным, чем диски, что создает сложности при создании и эффективном управлении файловой системой общего назначения. В дисковой файловой системе обычно используется главный каталог файлов и карта занятых и свободных областей данных. Любые добавления, изменения или удаления файлов требуют обновления каталога и карт занятых/свободных областей. Произвольный доступ к областям данных измеряется миллисекундами, поэтому эта система хорошо подходит для дисков. Лента требует линейного перемещения для намотки и размотки потенциально очень длинных лент. Это перемещение ленты может занимать от нескольких секунд до нескольких минут, чтобы переместить головку чтения/записи с одного конца ленты на другой. Следовательно, главный каталог файлов и карта использования могут быть чрезвычайно медленными и неэффективными при работе с лентой. Запись обычно включает в себя чтение карты использования блоков для поиска свободных блоков для записи, обновление карты использования и каталога для добавления данных, а затем перемещение ленты для записи данных в нужное место. Каждая дополнительная запись файла требует обновления карты и каталога и записи данных, что может занять несколько секунд на каждый файл. Вместо этого файловые системы для ленты обычно позволяют распределять каталог файлов по всей ленте, перемешивая его с данными (это называется потоковой записью), чтобы избежать трудоемких и многократных перемещений ленты при записи новых данных. Однако побочным эффектом этой конструкции является то, что для чтения каталога файлов ленты обычно требуется сканирование всей ленты для чтения всех разбросанных записей каталога. Большинство программ для архивирования данных, работающих с ленточным хранилищем, хранят локальную копию каталога ленты на дисковой файловой системе, чтобы добавление файлов на ленту можно было выполнять быстро, без необходимости повторного сканирования ленточного носителя. Локальная копия каталога ленты обычно удаляется, если она не используется в течение определенного периода времени, после чего ленту необходимо повторно сканировать, если она будет использоваться в будущем. Компания IBM разработала файловую систему для ленты под названием Linear Tape File System. Реализация этой файловой системы от IBM была выпущена как продукт с открытым исходным кодом IBM Linear Tape File System — Single Drive Edition (LTFS SDE). Linear Tape File System использует отдельный раздел на ленте для записи метаданных индекса, тем самым избегая проблем, связанных с разбросанными записями каталога по всей ленте.

A tape file system is a file system and tape format designed to store files on tape. Magnetic tapes are sequential storage media with significantly longer random data access times than disks, posing challenges to the creation and efficient management of a general purpose file system. In a disk file system there is typically a master file directory, and a map of used and free data regions. Any file additions, changes, or removals require updating the directory and the used/free maps. Random access to data regions is measured in milliseconds so this system works well for disks. Tape requires linear motion to wind and unwind potentially very long reels of media. This tape motion may take several seconds to several minutes to move the read/write head from one end of the tape to the other. Consequently, a master file directory and usage map can be extremely slow and inefficient with tape. Writing typically involves reading the block usage map to find free blocks for writing, updating the usage map and directory to add the data, and then advancing the tape to write the data in the correct spot. Each additional file write requires updating the map and directory and writing the data, which may take several seconds to occur for each file. Tape file systems instead typically allow for the file directory to be spread across the tape intermixed with the data, referred to as streaming, so that time consuming and repeated tape motions are not required to write new data. However, a side effect of this design is that reading the file directory of a tape usually requires scanning the entire tape to read all the scattered directory entries. Most data archiving software that works with tape storage will store a local copy of the tape catalog on a disk file system, so that adding files to a tape can be done quickly without having to rescan the tape media. The local tape catalog copy is usually discarded if not used for a specified period of time, at which point the tape must be re scanned if it is to be used in the future. IBM has developed a file system for tape called the Linear Tape File System. The IBM implementation of this file system has been released as the open source IBM Linear Tape File System — Single Drive Edition (LTFS SDE) product. The Linear Tape File System uses a separate partition on the tape to record the index meta data, thereby avoiding the problems associated with scattering directory entries across the entire tape.

Форматирование ленты

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

Транзакционные файловые системы

Некоторым программам необходимо либо внести несколько изменений в файловую систему, либо, если одно или несколько изменений не удается по какой-либо причине, не вносить никаких изменений. Например, программа, устанавливающая или обновляющая программное обеспечение, может записывать исполняемые файлы, библиотеки и/или файлы конфигурации. Если часть записи не удается, и программное обеспечение остается частично установленным или обновленным, оно может оказаться поврежденным или непригодным для использования. Неполное обновление ключевой системной утилиты, такой как командная оболочка, может привести к тому, что вся система станет непригодной для использования. Обработка транзакций обеспечивает гарантию атомарности, гарантируя, что операции внутри транзакции либо будут полностью выполнены, либо транзакция будет прервана, и система отбросит все ее частичные результаты. Это означает, что в случае сбоя или отключения электроэнергии после восстановления сохраненное состояние будет согласованным. Либо программное обеспечение будет полностью установлено, либо неудачная установка будет полностью отменена, но неработоспособная частичная установка не останется в системе. Транзакции также обеспечивают гарантию изоляции, что означает, что операции в рамках транзакции скрыты от других потоков в системе до момента фиксации транзакции, и что любые мешающие операции в системе будут правильно сериализованы с транзакцией. Windows, начиная с Vista, добавила поддержку транзакций в NTFS в виде функции Transactional NTFS, но ее использование сейчас не рекомендуется. Существует ряд исследовательских прототипов транзакционных файловых систем для систем UNIX, включая файловую систему Valor, Amino, LFS и транзакционную файловую систему ext3 на ядре TxOS, а также транзакционные файловые системы, предназначенные для встраиваемых систем, такие как TFFS. Обеспечение согласованности между несколькими операциями файловой системы затруднительно, если не невозможно, без транзакций файловой системы. Блокировка файлов может использоваться в качестве механизма управления параллелизмом для отдельных файлов, но обычно она не защищает структуру каталогов или метаданные файлов. Например, блокировка файлов не может предотвратить условия гонки TOCTTOU на символических ссылках. Блокировка файлов также не может автоматически отменить неудачную операцию, такую как обновление программного обеспечения; для этого требуется атомарность. Журналируемые файловые системы — это один из методов, используемых для обеспечения согласованности на уровне транзакций в структурах файловой системы. Журнальные транзакции не предоставляются программам как часть API ОС; они используются только внутри для обеспечения согласованности в гранулярности одного системного вызова. Системы резервного копирования данных обычно не поддерживают прямое резервное копирование данных, хранящихся транзакционным способом, что затрудняет восстановление надежных и согласованных наборов данных. Большинство программ для резервного копирования просто отмечают, какие файлы изменились с определенного момента времени, независимо от транзакционного состояния, общего для нескольких файлов в общем наборе данных. В качестве обходного пути некоторые системы баз данных просто создают архивный файл состояния, содержащий все данные на данный момент, а программное обеспечение для резервного копирования только копирует его и вообще не взаимодействует напрямую с активными транзакционными базами данных. Восстановление требует отдельного воссоздания базы данных из файла состояния после восстановления файла программным обеспечением для резервного копирования.

Some programs need to either make multiple file system changes, or, if one or more of the changes fail for any reason, make none of the changes. For example, a program which is installing or updating software may write executables, libraries, and/or configuration files. If some of the writing fails and the software is left partially installed or updated, the software may be broken or unusable. An incomplete update of a key system utility, such as the command shell, may leave the entire system in an unusable state. Transaction processing introduces the atomicity guarantee, ensuring that operations inside of a transaction are either all committed or the transaction can be aborted and the system discards all of its partial results. This means that if there is a crash or power failure, after recovery, the stored state will be consistent. Either the software will be completely installed or the failed installation will be completely rolled back, but an unusable partial install will not be left on the system. Transactions also provide the isolation guarantee, meaning that operations within a transaction are hidden from other threads on the system until the transaction commits, and that interfering operations on the system will be properly serialized with the transaction. Windows, beginning with Vista, added transaction support to NTFS, in a feature called Transactional NTFS, but its use is now discouraged. There are a number of research prototypes of transactional file systems for UNIX systems, including the Valor file system, Amino, LFS, and a transactional ext3 file system on the TxOS kernel, as well as transactional file systems targeting embedded systems, such as TFFS. Ensuring consistency across multiple file system operations is difficult, if not impossible, without file system transactions. File locking can be used as a concurrency control mechanism for individual files, but it typically does not protect the directory structure or file metadata. For instance, file locking cannot prevent TOCTTOU race conditions on symbolic links. File locking also cannot automatically roll back a failed operation, such as a software upgrade; this requires atomicity. Journaling file systems is one technique used to introduce transaction level consistency to file system structures. Journal transactions are not exposed to programs as part of the OS API; they are only used internally to ensure consistency at the granularity of a single system call. Data backup systems typically do not provide support for direct backup of data stored in a transactional manner, which makes the recovery of reliable and consistent data sets difficult. Most backup software simply notes what files have changed since a certain time, regardless of the transactional state shared across multiple files in the overall dataset. As a workaround, some database systems simply produce an archived state file containing all data up to that point, and the backup software only backs that up and does not interact directly with the active transactional databases at all. Recovery requires separate recreation of the database from the state file after the file has been restored by the backup software.

Сетевые файловые системы

Сетевая файловая система — это файловая система, работающая как клиент удаленного протокола доступа к файлам и обеспечивающая доступ к файлам на сервере. Программы, использующие локальные интерфейсы, могут прозрачно создавать, управлять и получать доступ к иерархическим каталогам и файлам на удаленных компьютерах, подключенных к сети. Примеры сетевых файловых систем включают клиенты протоколов NFS, AFS, SMB, а также файловые системы, функционирующие как клиенты для FTP и WebDAV.

Общие файловые системы дисков

Общая файловая система диска – это файловая система, к которой одновременно имеют доступ несколько машин (обычно серверов), использующих одну и ту же внешнюю подсистему дисков (обычно сеть хранения данных). Файловая система управляет доступом к этой подсистеме, предотвращая конфликты при записи. Примеры включают GFS2 от Red Hat, GPFS, ныне известную как Spectrum Scale, от IBM, SFS от DataPlow, CXFS от SGI, StorNext от Quantum Corporation и ScoutFS от Versity.

Минимальная файловая система / аудиокассеты

В 1970-х годах дисковые устройства и цифровые магнитофоны были слишком дороги для некоторых ранних пользователей микрокомпьютеров. Была разработана недорогая базовая система хранения данных, использовавшая обычные аудиокассеты. Когда системе требовалось записать данные, пользователю предлагалось нажать кнопку "RECORD" на кассетном магнитофоне, а затем "RETURN" на клавиатуре, чтобы сообщить системе о начале записи. Система записывала звуковой сигнал для временной синхронизации, а затем модулировала звуки, кодирующие префикс, данные, контрольную сумму и суффикс. Когда системе требовалось прочитать данные, пользователю предлагалось нажать кнопку "PLAY" на кассетном магнитофоне. Система прослушивала звуки на ленте, ожидая момента, когда всплеск звука будет распознан как сигнал синхронизации. Затем система интерпретировала последующие звуки как данные. После завершения чтения данных система сообщала пользователю нажать кнопку "STOP" на кассетном магнитофоне. Это было примитивно, но (в основном) работало. Данные хранились последовательно, как правило, в безымянном формате, хотя некоторые системы (например, компьютеры серии Commodore PET) позволяли присваивать имена файлам. Несколько наборов данных можно было записать и найти, быстро прокручивая ленту и ориентируясь по счетчику ленты, чтобы найти приблизительное начало следующей области данных. Пользователю, возможно, приходилось прослушивать звуки, чтобы определить правильное место для начала воспроизведения следующей области данных. В некоторых реализациях даже предусматривались слышимые звуки, чередующиеся с данными.

Плоские файловые системы

В плоской файловой системе отсутствуют подкаталоги; записи каталогов для всех файлов хранятся в одном каталоге. Когда впервые появились дискеты, этот тип файловой системы был достаточен из-за относительно небольшого объема доступного дискового пространства. Компьютеры CP/M использовали плоскую файловую систему, в которой файлы могли быть отнесены к одной из 16 пользовательских областей, а общие операции с файлами были ограничены работой только с выбранной областью вместо работы по умолчанию со всеми файлами. Эти пользовательские области были не более чем специальными атрибутами, связанными с файлами; то есть не требовалось определять конкретные квоты для каждой из этих областей, и файлы можно было добавлять в группы, пока на диске оставалось свободное место. Ранние компьютеры Apple Macintosh также использовали плоскую файловую систему – Macintosh File System. Она была необычной тем, что программа управления файлами (Macintosh Finder) создавала иллюзию частично иерархической файловой системы поверх EMFS. Эта структура требовала, чтобы каждый файл имел уникальное имя, даже если он казался расположенным в отдельной папке. IBM DOS/360 и OS/360 хранят записи для всех файлов на дисковом блоке (томе) в каталоге на блоке, называемом таблицей содержания тома (VTOC). Хотя плоские файловые системы просты, они становятся неудобными по мере увеличения количества файлов и затрудняют организацию данных в связанные группы. Недавним дополнением к семейству плоских файловых систем является S3 от Amazon – служба удаленного хранения, которая намеренно упрощена, чтобы предоставить пользователям возможность настраивать способ хранения данных. Единственными структурами являются корзины (представьте себе дисковый накопитель неограниченного размера) и объекты (похожие, но не идентичные стандартному понятию файла). Расширенное управление файлами обеспечивается возможностью использования практически любого символа (включая '/') в имени объекта и возможностью выбора подмножеств содержимого корзины на основе идентичных префиксов.

Реализация

Операционная система (ОС) обычно поддерживает одну или несколько файловых систем. Иногда ОС и её файловая система настолько тесно связаны, что их сложно описать по отдельности. ОС обычно предоставляет пользователю доступ к файловой системе. Часто ОС обеспечивает интерфейс командной строки, например, Unix shell, Windows Command Prompt и PowerShell, а также OpenVMS DCL. ОС часто также предоставляет графические файловые менеджеры, такие как MacOS Finder и Windows File Explorer.

Операционные системы Unix и Unix-подобные

Операционные системы, подобные Unix, создают виртуальную файловую систему, которая представляет все файлы на всех устройствах как существующие в единой иерархии. Это означает, что в этих системах есть один корневой каталог, и каждый файл, существующий в системе, расположен где-то в его поддереве. Системы, подобные Unix, могут использовать RAM-диск или сетевой ресурс в качестве корневого каталога. Unix-подобные системы присваивают каждому устройству имя, но доступ к файлам на этом устройстве осуществляется не по этому имени. Вместо этого, для получения доступа к файлам на другом устройстве операционная система должна сначала узнать, где в дереве каталогов эти файлы должны отображаться. Этот процесс называется монтированием файловой системы. Например, для доступа к файлам на CD-ROM необходимо сообщить операционной системе: "Возьмите файловую систему с этого CD-ROM и отобразите её в таком-то каталоге". Каталог, предоставляемый операционной системе, называется точкой монтирования. Например, каталог `/mnt` существует во многих Unix-системах (как указано в Стандарте иерархии файловой системы) и предназначен специально для использования в качестве точки монтирования для съемных носителей, таких как CD, DVD, USB-накопители или дискеты. Он может быть пустым или содержать подкаталоги для монтирования отдельных устройств. Как правило, только администратор (т.е. пользователь root) может разрешить монтирование файловых систем. Операционные системы, подобные Unix, часто включают программное обеспечение и инструменты, которые помогают в процессе монтирования и добавляют новые функции. Некоторые из этих стратегий получили название "автоматического монтирования", отражая их назначение. Во многих ситуациях файловые системы, отличные от корневой, должны быть доступны сразу после загрузки операционной системы. Поэтому все Unix-подобные системы предоставляют возможность монтирования файловых систем во время загрузки. Системные администраторы определяют эти файловые системы в файле конфигурации `fstab` (в Solaris – `vfstab`), который также указывает параметры и точки монтирования. В некоторых ситуациях нет необходимости монтировать определенные файловые системы во время загрузки, хотя их использование может потребоваться впоследствии. Существуют утилиты для Unix-подобных систем, которые позволяют монтировать предопределенные файловые системы по требованию. Съемные носители позволяют передавать программы и данные между машинами без физического соединения. Распространенные примеры включают USB-флеш-накопители, CD-ROM и DVD-диски. Поэтому были разработаны утилиты для обнаружения наличия и доступности носителя и последующего его монтирования без вмешательства пользователя. Продвинутые Unix-подобные системы также ввели концепцию, называемую супермонтированием; например, проект Linux supermount-ng. Например, гибкий диск, который был супермонтирован, можно физически извлечь из системы. В нормальных условиях диск должен быть синхронизирован и затем размонтирован перед извлечением. Если синхронизация выполнена, в устройство можно вставить другой диск. Система автоматически обнаруживает изменение диска и обновляет содержимое точки монтирования, чтобы отразить новый носитель. Автоматический монтировщик (automounter) автоматически монтирует файловую систему при обращении к каталогу, на котором она должна быть установлена. Обычно это используется для файловых систем на сетевых серверах, а не для событий, таких как вставка носителя, что было бы уместно для съемных носителей.

Unix like operating systems create a virtual file system, which makes all the files on all the devices appear to exist in a single hierarchy. This means, in those systems, there is one root directory, and every file existing on the system is located under it somewhere. Unix like systems can use a RAM disk or network shared resource as its root directory. Unix like systems assign a device name to each device, but this is not how the files on that device are accessed. Instead, to gain access to files on another device, the operating system must first be informed where in the directory tree those files should appear. This process is called mounting a file system. For example, to access the files on a CD ROM, one must tell the operating system "Take the file system from this CD ROM and make it appear under such and such directory." The directory given to the operating system is called the mount point – it might, for example, be The directory exists on many Unix systems (as specified in the Filesystem Hierarchy Standard) and is intended specifically for use as a mount point for removable media such as CDs, DVDs, USB drives or floppy disks. It may be empty, or it may contain subdirectories for mounting individual devices. Generally, only the administrator (i. e. root user) may authorize the mounting of file systems. Unix like operating systems often include software and tools that assist in the mounting process and provide it new functionality. Some of these strategies have been coined "auto mounting" as a reflection of their purpose. In many situations, file systems other than the root need to be available as soon as the operating system has booted. All Unix like systems therefore provide a facility for mounting file systems at boot time. System administrators define these file systems in the configuration file fstab (vfstab in Solaris), which also indicates options and mount points. In some situations, there is no need to mount certain file systems at boot time, although their use may be desired thereafter. There are some utilities for Unix like systems that allow the mounting of predefined file systems upon demand. Removable media allow programs and data to be transferred between machines without a physical connection. Common examples include USB flash drives, CD ROMs, and DVDs. Utilities have therefore been developed to detect the presence and availability of a medium and then mount that medium without any user intervention. Progressive Unix like systems have also introduced a concept called supermounting; see, for example, the Linux supermount ng project. For example, a floppy disk that has been supermounted can be physically removed from the system. Under normal circumstances, the disk should have been synchronized and then unmounted before its removal. Provided synchronization has occurred, a different disk can be inserted into the drive. The system automatically notices that the disk has changed and updates the mount point contents to reflect the new medium. An automounter will automatically mount a file system when a reference is made to the directory atop which it should be mounted. This is usually used for file systems on network servers, rather than relying on events such as the insertion of media, as would be appropriate for removable media.

Линукс

Linux поддерживает множество файловых систем, но наиболее распространенными вариантами для системного диска на блочном устройстве являются семейства ext* (ext2, ext3 и ext4), XFS, JFS и btrfs. Для сырой флеш-памяти без слоя трансляции флеш-памяти (FTL) или устройства технологии памяти (MTD) доступны UBIFS, JFFS2 и YAFFS, среди прочих. SquashFS – это распространенная сжатая файловая система, предназначенная только для чтения.

Солярис

Solaris в ранних версиях по умолчанию использовала UFS (не журналируемую или не ведущую журнал) для загрузочных и дополнительных файловых систем. Solaris по умолчанию поддерживала и развивала UFS. Со временем была добавлена поддержка других файловых систем и значительные улучшения, включая VxFS от Veritas Software Corp. (с журналированием), QFS от Sun Microsystems (с кластеризацией), UFS от Sun Microsystems (с журналированием) и ZFS от Sun Microsystems (открытый исходный код, объединяемая, 128-битная сжимаемая и с коррекцией ошибок). В Solaris были добавлены расширения ядра для обеспечения загрузки с Veritas VxFS. Журналирование или ведение журнала было добавлено в UFS в Solaris 7 от Sun. Выпуски Solaris 10, Solaris Express, OpenSolaris и другие варианты операционной системы Solaris с открытым исходным кодом позже поддерживали загрузочный ZFS. Логическое управление томами позволяет расширять файловую систему на несколько устройств для обеспечения избыточности, емкости и/или производительности. В устаревших средах Solaris может использоваться Solaris Volume Manager (ранее известный как Solstice DiskSuite). Несколько операционных систем (включая Solaris) могут использовать Veritas Volume Manager. Современные операционные системы на базе Solaris делают ненужным управление томами благодаря использованию виртуальных пулов хранения в ZFS.

macOS

macOS (ранее Mac OS X) использует файловую систему Apple (APFS), которая в 2017 году заменила файловую систему, унаследованную от классической Mac OS, под названием HFS Plus (HFS+). Apple также использует термин "Mac OS Extended" для HFS+. HFS Plus — это файловая система, богатая метаданными, сохраняющая регистр символов, но (обычно) нечувствительная к нему. Благодаря корням macOS в Unix, в HFS Plus были добавлены права доступа Unix. В более поздних версиях HFS Plus был реализован журнал для предотвращения повреждения структуры файловой системы и внесены многочисленные оптимизации в алгоритмы выделения, чтобы попытаться автоматически дефрагментировать файлы без необходимости использования внешнего дефрагментатора. Имена файлов могут содержать до 255 символов. HFS Plus использует Unicode для хранения имён файлов. В macOS тип файла может определяться по коду типа, хранящемуся в метаданных файла, или по расширению имени файла. HFS Plus поддерживает три типа ссылок: жесткие ссылки в стиле Unix, символические ссылки в стиле Unix и псевдонимы. Псевдонимы предназначены для сохранения связи с исходным файлом, даже если он перемещён или переименован; они интерпретируются не самой файловой системой, а кодом File Manager в пространстве пользователя (userland). macOS 10.13 High Sierra, представленная 5 июня 2017 года на мероприятии WWDC от Apple, использует файловую систему Apple на твердотельных накопителях. macOS также поддерживала файловую систему UFS, производную от BSD Unix Fast File System через NeXTSTEP. Однако, начиная с Mac OS X Leopard, установка macOS на UFS-том стала невозможной, а системы, установленные на UFS до Leopard, не могут быть обновлены до Leopard. Поддержка UFS была полностью прекращена с Mac OS X Lion. Более новые версии macOS способны читать и записывать устаревшие файловые системы FAT (16 и 32), распространённые в Windows. Они также способны читать более новые файловые системы NTFS для Windows. Для записи на файловые системы NTFS в версиях macOS до Mac OS X Snow Leopard требуется стороннее программное обеспечение. Mac OS X 10.6 (Snow Leopard) и более поздние версии позволяют записывать файлы на файловые системы NTFS, но только после внесения изменений в нетривиальные системные настройки (существует стороннее программное обеспечение, которое автоматизирует этот процесс). Наконец, macOS поддерживает чтение и запись файловой системы exFAT с Mac OS X Snow Leopard, начиная с версии 10.6.5.

macOS (formerly Mac OS X) uses the Apple File System (APFS), which in 2017 replaced a file system inherited from classic Mac OS called HFS Plus (HFS+). Apple also uses the term "Mac OS Extended" for HFS+. HFS Plus is a metadata rich and case preserving but (usually) case insensitive file system. Due to the Unix roots of macOS, Unix permissions were added to HFS Plus. Later versions of HFS Plus added journaling to prevent corruption of the file system structure and introduced a number of optimizations to the allocation algorithms in an attempt to defragment files automatically without requiring an external defragmenter. File names can be up to 255 characters. HFS Plus uses Unicode to store file names. On macOS, the filetype can come from the type code, stored in file's metadata, or the filename extension. HFS Plus has three kinds of links: Unix style hard links, Unix style symbolic links, and aliases. Aliases are designed to maintain a link to their original file even if they are moved or renamed; they are not interpreted by the file system itself, but by the File Manager code in userland. macOS 10.13 High Sierra, which was announced on June 5, 2017, at Apple's WWDC event, uses the Apple File System on solid state drives. macOS also supported the UFS file system, derived from the BSD Unix Fast File System via NeXTSTEP. However, as of Mac OS X Leopard, macOS could no longer be installed on a UFS volume, nor can a pre Leopard system installed on a UFS volume be upgraded to Leopard. As of Mac OS X Lion UFS support was completely dropped. Newer versions of macOS are capable of reading and writing to the legacy FAT file systems (16 and 32) common on Windows. They are also capable of reading the newer NTFS file systems for Windows. In order to write to NTFS file systems on macOS versions prior to Mac OS X Snow Leopard third party software is necessary. Mac OS X 10.6 (Snow Leopard) and later allow writing to NTFS file systems, but only after a non trivial system setting change (third party software exists that automates this). Finally, macOS supports reading and writing of the exFAT file system since Mac OS X Snow Leopard, starting from version 10.6.5.

OS/2

OS/2 1.2 представила высокопроизводительную файловую систему (HPFS). HPFS поддерживает имена файлов с учетом регистра в различных кодовых страницах, длинные имена файлов (255 символов), более эффективное использование дискового пространства, архитектуру, при которой связанные данные располагаются близко друг к другу на диске, меньшую фрагментацию данных, распределение пространства на основе экстентов, структуру B+ дерева для каталогов и корневой каталог, расположенный в середине диска, для более быстрого среднего времени доступа. Файловая система с журналированием (Journaled File System, JFS) была выпущена в 1999 году.

ПК-БСД

PC BSD — это настольная версия FreeBSD, которая наследует поддержку ZFS от FreeBSD, как и FreeNAS. Новый графический установщик PC BSD позволяет легко и удобно (через GUI) устанавливать систему с корневым разделом (/) на ZFS и в RAID Z, а также сразу же настроить шифрование диска с помощью Geli. В текущей PC BSD 9.0+ "Isotope Edition" используется ZFS файловая система версии 5 и ZFS пул хранения версии 28.

План 9

Plan 9 от Bell Labs рассматривает всё как файл и обращается ко всем объектам как к файлу (то есть не используются ioctl или mmap): сетевые возможности, графика, отладка, аутентификация, права доступа, шифрование и другие сервисы доступны посредством операций ввода-вывода с использованием файловых дескрипторов. Протокол 9P стирает различие между локальными и удалёнными файлами. Файловые системы в Plan 9 организованы с помощью приватных пространств имён для каждого процесса, что позволяет каждому процессу иметь собственное представление о множестве файловых систем, предоставляющих ресурсы в распределённой системе. Операционная система Inferno разделяет эти концепции с Plan 9.

Microsoft Windows

Windows использует файловые системы FAT, NTFS, exFAT, Live File System и ReFS (последняя из них поддерживается и может использоваться только в Windows Server 2012, Windows Server 2016, Windows 8, Windows 8.1 и Windows 10; загрузка с нее в Windows невозможна). Windows использует абстракцию букв дисков на уровне пользователя для различения дисков и разделов. Например, путь обозначает каталог на разделе, обозначенном буквой C. Диск C: чаще всего используется для основного раздела жесткого диска, на котором обычно установлена Windows и с которого осуществляется загрузка. Эта "традиция" настолько укоренилась, что во многих приложениях встречаются ошибки, основанные на предположении, что операционная система установлена на диске C. Использование букв дисков и традиция присвоения буквы "C" основному разделу жесткого диска восходят к MS-DOS, где буквы A и B были зарезервированы для максимум двух дисководов. Это, в свою очередь, берет начало в CP/M 1970-х годов, а еще раньше – в CP/CMS компании IBM 1967 года.

ЖИРНО

Семья файловых систем FAT поддерживается практически всеми операционными системами для персональных компьютеров, включая все версии Windows и MS DOS/PC DOS, OS/2 и DR DOS. (PC DOS – это OEM-версия MS DOS, MS DOS изначально была основана на SCP 86 DOS. DR DOS был основан на Concurrent DOS от Digital Research, преемнике CP/M 86.) Поэтому файловые системы FAT хорошо подходят в качестве универсального формата обмена между компьютерами и устройствами практически любого типа и возраста. История файловой системы FAT берет начало в (несовместимом) 8-битном предшественнике FAT в Standalone Disk BASIC и кратко существовавшем проекте MDOS/MIDAS. С годами файловая система была расширена от FAT12 до FAT16 и FAT32. В файловую систему были добавлены различные функции, включая подкаталоги, поддержку кодовых страниц, расширенные атрибуты и длинные имена файлов. Сторонние разработчики, такие как Digital Research, добавили опциональную поддержку отслеживания удаления, а также многопользовательские схемы безопасности, основанные на томах/каталогах/файлах, для поддержки паролей и разрешений файлов и каталогов, таких как права доступа на чтение/запись/выполнение/удаление. Большинство этих расширений не поддерживаются Windows. Файловые системы FAT12 и FAT16 имели ограничение на количество записей в корневом каталоге файловой системы и ограничения на максимальный размер дисков или разделов, отформатированных в FAT. FAT32 устраняет ограничения FAT12 и FAT16, за исключением ограничения на размер файла около 4 ГБ, но по-прежнему ограничена по сравнению с NTFS. FAT12, FAT16 и FAT32 также имеют ограничение в восемь символов для имени файла и три символа для расширения (например, exe). Это обычно называют ограничением 8.3 для имен файлов. VFAT, необязательное расширение для FAT12, FAT16 и FAT32, представленное в Windows 95 и Windows NT 3.5, позволило хранить длинные имена файлов (LFN) в файловой системе FAT, обеспечивая обратную совместимость.

NTFS

NTFS, представленная с операционной системой Windows NT в 1993 году, обеспечивала контроль разрешений на основе ACL. Среди других поддерживаемых NTFS функций – жесткие ссылки, множественные потоки файлов, индексирование атрибутов, отслеживание квот, разреженные файлы, шифрование, сжатие и точки повторного анализа (каталоги, функционирующие как точки монтирования для других файловых систем, символические ссылки, соединения, ссылки на удаленное хранилище).

exFAT

exFAT имеет определенные преимущества перед NTFS в отношении накладных расходов файловой системы. exFAT не обеспечивает обратную совместимость с файловыми системами FAT, такими как FAT12, FAT16 или FAT32. Эта файловая система поддерживается в новых версиях Windows, включая Windows XP, Windows Server 2003, Windows Vista, Windows 2008, Windows 7, Windows 8, Windows 8.1, Windows 10 и Windows 11.

Поддержка exFAT в macOS реализована, начиная с версии 10.6.5 (Snow Leopard).

MVS

До введения VSAM, в системах OS/360 использовалась гибридная файловая система. Система была спроектирована с учетом простой поддержки съемных дисковых блоков, поэтому информация обо всех файлах на одном диске (томе, в терминологии IBM) хранится на этом диске в плоском системном файле, называемом таблицей содержания тома (VTOC). VTOC хранит все метаданные файла. Впоследствии была внедрена иерархическая структура каталогов с появлением System Catalog, который может опционально каталогизировать файлы (наборы данных) на резидентных и съемных томах. Каталог содержит только информацию, необходимую для связи набора данных с конкретным томом. Если пользователь запрашивает доступ к набору данных на не подключенном томе и имеет соответствующие права, система попытается подключить необходимый том. К каталогизированным и некаталогизированным наборам данных можно получить доступ, используя информацию в VTOC, минуя каталог, если в запросе OPEN указан требуемый идентификатор тома. Позже VTOC был индексирован для ускорения доступа.

Система мониторинга разговора

Компонент IBM Conversational Monitor System (CMS) системы VM/370 использует отдельную плоскую файловую систему для каждого виртуального диска (минидиска). Данные файлов и управляющая информация разбросаны и перемешаны. Основным элементом является запись, называемая "Главный каталог файлов" (Master File Directory, MFD), которая всегда находится в четвертом блоке диска. Изначально CMS использовал блоки фиксированной длины 800 байт, но в более поздних версиях использовались блоки большего размера, до 4К. Доступ к записи данных требует двух уровней косвенной адресации, где запись каталога файла (называемая записью таблицы состояния файла (FST)) указывает на блоки, содержащие список адресов отдельных записей.

Файловая система AS/400

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

Ограничения конструкции

Файловые системы ограничивают объём хранимых данных, что обычно определяется типичным размером устройств хранения на момент разработки файловой системы и прогнозируемым размером в обозримом будущем. Поскольку объёмы хранения данных растут почти экспоненциально (см. закон Мура), новые устройства хранения часто превышают существующие ограничения файловых систем всего через несколько лет после появления. Это требует разработки новых файловых систем с постоянно увеличивающимся объёмом. С ростом объёма растёт и потребность в дополнительных функциях, а следовательно, и сложность. Сложность файловой системы обычно пропорциональна доступному объёму хранения. Отбросив вопросы объёма, файловые системы домашних компьютеров начала 1980-х годов с объёмом хранения от 50 КБ до 512 КБ не подходили бы для современных систем хранения данных с сотнями гигабайт. И наоборот, современные файловые системы не подходили бы для этих ранних систем, поскольку сложность современных структур файловых систем быстро исчерпала бы ограниченный объём ранних устройств хранения.

Преобразование типа файловой системы

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

Преобразование на месте

В некоторых случаях преобразование можно выполнить на месте, хотя миграция файловой системы является более надёжным подходом, поскольку предполагает создание копии данных и рекомендуется к использованию. В Windows файловые системы FAT и FAT32 можно преобразовать в NTFS с помощью утилиты convert.exe, но обратное преобразование невозможно. Файловые системы ext3 и ext4 можно преобразовать в btrfs и вернуть обратно, пока не удалена информация для отмены изменений. Такие преобразования возможны благодаря использованию одного и того же формата для самих данных файлов и перемещению метаданных в свободное пространство, в некоторых случаях с использованием поддержки разреженных файлов.

Миграция в другую файловую систему

Миграция имеет недостаток, заключающийся в требовании дополнительного пространства, хотя она может выполняться быстрее. Наилучший сценарий – наличие неиспользуемого пространства на носителе, который будет содержать конечную файловую систему. Например, при миграции файловой системы FAT32 в файловую систему ext2 создается новая файловая система ext2. Затем данные из файловой системы FAT32 копируются в ext2, после чего старая файловая система удаляется. Если же недостаточно места для сохранения исходной файловой системы до создания новой, альтернативным решением является использование рабочей области (например, съемного носителя). Это занимает больше времени, но позволяет создать резервную копию.

Длинные пути и длинные имена файлов

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