Файловые системы: что это, какие бывают и как выбрать

Файловая система (ФС) — это способ, которым операционная система размещает данные на томе и находит их снова: как устроены имена и каталоги, где лежат блоки файла, какие у него права и метаданные, что происходит при сбое. Сам носитель (диск, SSD, флешка) и раздел на нем — это не ФС: ФС создается поверх раздела при форматировании.

Ниже — мини-словарь, устройство ФС, журналирование и copy-on-write, сравнение распространенных ФС для Windows, Linux и macOS, практика на файле-образе и правило выбора. Особенности именно Windows (NTFS, ReFS, настройки форматирования) здесь только в объеме сравнения.

Мини-словарь: носитель, раздел, том, файловая система

Цепочка на одном примере: флешка -> раздел /dev/sdb1 в таблице GPT -> том -> ФС exFAT -> файл report.pdf, который ОС видит как /media/user/USB/report.pdf или E:\report.pdf.

Как устроена файловая система

Упрощенная модель, общая для большинства ФС (детали различаются):

• Блоки (кластеры). Том поделен на блоки фиксированного размера, часто 4 КиБ. Файл занимает целое число блоков, поэтому файл в 1 байт все равно тратит один блок (кроме ФС, умеющих хранить мелкие файлы прямо в метаданных).
• Метаданные файла. Размер, время изменения, владелец, права, список блоков. В ext4 это inode, в NTFS — запись в MFT, в FAT — запись каталога плюс цепочка в таблице FAT.
• Каталоги. Отображение «имя -> метаданные». Имя файла в Unix-подобных ФС хранится в каталоге, а не в inode, поэтому у одного файла может быть несколько жестких ссылок.
• Учет свободного места. Битовые карты, таблицы или деревья экстентов.

Приложение этих деталей не видит: оно вызывает open, read, write через ОС, а драйвер ФС переводит вызов в операции с блоками.

Журналирование и copy-on-write: что спасает от сбоя

Запись файла — это несколько изменений: выделить блоки, записать данные, обновить метаданные и каталог. Если питание пропало посередине, структура может остаться противоречивой. Против этого есть два основных подхода.

Журналирование. ФС сначала записывает намерение изменения в журнал, потом применяет его. После сбоя журнал «доигрывается» или откатывается, и полная проверка тома не нужна. Важная граница: ext4 в режиме по умолчанию (data=ordered) и NTFS журналируют метаданные, а не содержимое файлов. Структура ФС будет цела, но последние данные файла, не дошедшие до диска, могут потеряться.

Copy-on-write (CoW). Измененные данные пишутся в новое место, а старая версия не перезаписывается; в конце атомарно переключается указатель на новое состояние. Так работают APFS, Btrfs и ZFS. Отсюда дешевые снимки (snapshots) и клоны. Btrfs и ZFS дополнительно считают контрольные суммы данных и замечают тихую порчу; при избыточности (зеркало) ZFS и Btrfs умеют ее исправить.

Ни журнал, ни CoW не заменяют резервную копию: они защищают согласованность ФС, но не от удаления файла, шифровальщика или отказа диска.

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

Главный практический лимит FAT32 — файл не больше 4 ГиБ минус 1 байт. У exFAT, NTFS, ext4, XFS, APFS, Btrfs и ZFS пределы размера файла и тома на порядки выше того, что встречается на обычном ПК, и для выбора они обычно не решают. Точные цифры зависят от размера блока и реализации драйвера, поэтому сравнивать их «в лоб» без этих условий некорректно.

Практика: создать ФС на файле-образе в Linux

Безопасный способ увидеть форматирование своими глазами — сделать его не на диске, а на обычном файле. Команды mkfs на реальном устройстве уничтожают его содержимое без корзины, поэтому здесь целью служит только файл в /tmp.

#!/usr/bin/env bash
set -euo pipefail
IMG=/tmp/fs-demo.img
MNT=/tmp/fs-demo-mnt

[ ! -e "$IMG" ] || { echo "$IMG уже существует, выход"; exit 1; }  # не затирать чужой файл
truncate -s 64M "$IMG"          # пустой файл 64 МиБ, диск не трогаем
test -f "$IMG"                  # защита: цель - обычный файл, не устройство
trap 'sudo umount "$MNT" 2>/dev/null || true; rm -f "$IMG"' EXIT  # уборка при любом исходе
mkfs.ext4 -q "$IMG"             # создать ФС ext4 внутри файла
mkdir -p "$MNT"
sudo mount -o loop "$IMG" "$MNT" # подключить образ как том
df -hT "$MNT"

Вывод df, проверено в Ubuntu 24.04 (e2fsprogs 1.47.0) 23.09.2026; на других версиях цифры могут отличаться на 1-2 МиБ:

Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/loop0     ext4   56M   24K   52M   1% /tmp/fs-demo-mnt

Разбор: truncate создает файл нужного размера, mkfs.ext4 пишет в него структуры ФС (суперблок, группы блоков, таблицы inode, журнал), mount -o loop подключает файл через loop-устройство, df -T показывает тип ФС, а trap отмонтирует и удалит образ, даже если скрипт упадет посередине. Видно, что из 64 МиБ пользователю доступно меньше: часть места занимают метаданные и резерв для root.

Если все же форматируете реальный носитель: сначала lsblk -f и сверка модели и размера устройства, копия нужных данных, отключенный (umount) том, и только потом mkfs на конкретный раздел, а не на весь диск по ошибке.

Посмотреть, какие ФС уже используются на машине, можно без риска:

lsblk -f        # устройства, разделы, тип ФС, метки
findmnt -t ext4,xfs,btrfs,vfat,exfat,ntfs3

Типичная ошибка: большой файл на флешке FAT32

Неверно: скопировать образ размером 5 ГиБ на флешку, отформатированную в FAT32.

cp ubuntu.iso /media/user/USB/

Фактический результат в Linux (GNU coreutils 9.4; в старых версиях текст error writing ..., в Windows Проводник сообщит, что файл слишком велик для конечной файловой системы):

cp: failed to extend '/media/user/USB/ubuntu.iso': File too large

Исправление: сохранить данные с флешки и переформатировать ее в exFAT (читается Windows, macOS и Linux) или, если флешка нужна только для Windows, в NTFS. Сжатие обычно не помогает: ISO и видео почти не сжимаются, а лимит касается каждого файла, а не тома. Обычный архив можно разбить на части меньше 4 ГиБ (многотомный архив, split), но загрузочную флешку из такого образа не сделать.

Как выбрать файловую систему

Выбор строится от задачи, а не от «лучшей ФС»:

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

Выводы

• Файловая система — структура внутри тома, а не сам диск и не раздел; ее создает форматирование.
• Журналирование (NTFS, ext4, XFS) защищает согласованность метаданных, CoW (APFS, Btrfs, ZFS) дает снимки, а контрольные суммы Btrfs и ZFS ловят тихую порчу. Резервную копию не заменяет ничто из этого.
• Для обмена между ОС — exFAT; FAT32 оставьте для EFI и старых устройств из-за лимита файла 4 ГиБ.
• Для внутренних дисков — родная ФС: NTFS в Windows, ext4/XFS/Btrfs в Linux, APFS в macOS.
• Эксперименты с mkfs безопасно проводить на файле-образе, а реальный носитель форматировать только после lsblk -f и бэкапа.

Где применяется / связь с практикой

FAQ

Можно ли сменить файловую систему без потери данных?
В общем случае нет: форматирование создает новую структуру, поэтому данные нужно сохранить и вернуть. Отдельные утилиты конвертируют ФС на месте (например, ext4 в Btrfs), но и перед ними нужен бэкап.

Почему на новом диске доступно меньше места, чем написано на коробке?
Производитель считает в десятичных гигабайтах, а ОС часто показывает двоичные (ГиБ); плюс часть места занимают метаданные ФС и резерв.

Нужна ли дефрагментация SSD?
Нет: у SSD нет механической головки, а ОС для них выполняет TRIM. Windows делает это сама (служба «Оптимизация дисков»), macOS — автоматически для штатных SSD Apple; для стороннего SATA SSD в Mac TRIM включают командой sudo trimforce enable.