Как сделать файловую систему xfs

Обновлено: 22.01.2025

Журналируемая файловая система xfs позволяет использовать блочные устройства размером более 16ТБ (пакеты xfsprogs и xfsdump), первоначально была разработана для SGI IRIX, поддерживает расширенные атрибуты файлов, выделение места экстентами, эффективное распараллеливание за счёт разбиения области данных на независимые отсеки. Является файловой системой по умолчанию в RHEL 7. Не очень любит мелкие файлы. Предпочтительна при большом количестве потоков доступа.

состоит из секций данных (содержит метаданные и может содержать журнал), журнала и секции для работы в реальном времени
секция данных делится на равные группы блоков (allocation groups), количество которых определяет уровень параллелизма при выделении места; каждая группа содержит суперблок, управление свободным пространством группы, таблицу inode (создаются по потребности), данные
размер блока в Linux - 4 КБ
выделение места происходит экстентами (до 8 GiB)
ранее не подходила для хранения большого количества мелких файлов (почтовый сервер) - медленно работает с метаданными; постепенно улучшается
открытые в момент неожиданного выключения компьютера файлы будут заполнены нулями (исправлено)
мгновенное создание и расширение файловой системы при нулевых накладных расходах (у ext4 - 1.5%, т.е. 269GB для 16ТБ) и примерно сравнимых с ext4 накладных расходах при хранении файлов (на 0.07% меньше для набора в 10TB из 10 миллионов файлов
64-битные номера inode для файловой системы размером 2ТиБ и более, не все 32-битные программы это переживут ; исправлено в RHEL7

/proc/fs/xfs/stat - статистика
/proc/sys/fs/xfs - ручки управления
- age_buffer_centisecs - 1500, возраст метаданных для сброса на диск
- error_level (?)
- filestream_centisecs - 3000
- inherit_noatime
- inherit_nodefrag
- inherit_nodump
- inherit_nosymlinks
- inherit_sync
- irix_sgid_inherit
- irix_symlink_mode - позволяет устанавливать права доступа символьных ссылок (отключено)
- panic_mask (?)
- rotorstep - 1, сколько файлов размещать в группе перед переходом к следующей
- restrict_chown - запрещает передавать права на файл другим пользователям (отключено, нев в RHEL7)
- speculative_prealloc_lifetime (?)
- stats_clear (?)
- xfsbufd_centisecs - 100, интервал сборки мусора в буферах метаданных
- xfssyncd_centisecs - 3000, интервал сброса метаданных
Кстати, опыт показал, что xfs сбрасывает накопленные буфера с такой интенсивностью, что захлёбывается внешнее хранилише (RAID контроллер), поэтому рекомендуется обеспечить ранее начало сброса: 40000000 в /proc/sys/vm/dirty_bytes, 10000000 в /proc/sys/vm/dirty_background_bytes.

Проблема с излишней фрагментацией ("XFS: . possible memory allocation deadlock") купируется сбросом буферов в slab ("echo 2 > /proc/sys/vm/drop_caches"). У меня это произошло с индексным фйалом MySQL при добавлении ключа (файл 40ГБ оказался разбит на 3 миллиона кусочков).

xfs_info (скрипт для xfs_db).

xfs_admin (скрипт для xfs_db) позволяет изменить метку и UUID размонтированной фаловой системы.

xfs_check (скрипт для xfs_db) - проверка файловой системы, требуется размонтирование, требует 16 ГБ памяти (реально использовались 10 ГБ) для файловой системы в 7 TB (67%, 500 файлов); требует и реально использует 42 ГБ памяти для файловой системы в 20TB, быстр.

xfs_logprint - вывод и разбор журнала.

xfs_metadump (скрипт для xfs_db) - вывод метаданных в файл.

Определить уровень фрагментации файлов: "xfs_db -c frag -r блочное-устройство" (размонтирование не требуется, но иногда случается "Segmentation fault" ; показывает долю "лишних" экстентов).

Определить уровень фрагментации свободного пространства: "xfs_db -c freesp -r блочное-устройство" (размонтирование не требуется).
- -v
- -t секунд (7200; максимальное время работы)
- -L (обнулить журнал)
- -n (только проверка)
- -t секунд (интервал между отчётами)
- -v
Утилиты xfsdump и xfsrestore могут помочь извлечь данные из файловой системы, которой не помогла xfs_repair (требуется монтирование).

Утилита xfs_growfs позволяет увеличить размер файловой системы без размонтирования ( уменьшение размера файловой системы невозможно ).

Прочее: xfs_bmap, xfs_freeze, xfs_io, xfs_mdrestore, xfs_mkfile, xfs_ncheck, xfs_quota.
- подключить дисковый массив к контроллеру FibreChannel
- создать 2 массива RAID-6 (12x2TB) по 20TB, LUN во весь размер на каждом (24 диска в 1 LUN не умеет)
- создать логический том
- создать файловую систему
- монтирование (/etc/fstab)
- настройки в /etc/rc.local
- проверка скорости (линейная скорость ограничена здесь FC контроллером на 4Gb)
- множество примеров скоростных характеристик в статье про RAID
- 1 поток - 16911270150144 bytes (17 TB) copied, 60008.1 s, 282 MB/s
- 2 потока - 10441797402624 bytes (10 TB) copied, 32280.2 s, 323 MB/s
- 4 потока - 8016907730944 bytes (8.0 TB) copied, 15049.9 s, 533 MB/s
- 6 потоков - 15313932386304 bytes (15 TB) copied, 22621.3 s, 677 MB/s
- 8 потоков - 32895813025792 bytes (33 TB) copied, 42517.9 s, 774 MB/s
- 10 потоков - 30828863160320 bytes (31 TB) copied, 34851.2 s, 885 MB/s (пока их ещё 10)
- 12 потоков - 35113530294272 bytes (35 TB) copied, 39212.2 s, 895 MB/s (пока их ещё 6)
- 16 потоков - 17077979054080 bytes (17 TB) copied, 13573.9 s, 1.3 GB/s (пока их ещё 16)
- 20 потоков - 5592203657216 bytes (5.6 TB) copied, 3784.57 s, 1.5 GB/s (пока их 20)
- 24 потока - 6714306854912 bytes (6.7 TB) copied, 8835.18 s, 760 MB/s (пока их 20)
- 32 потока - 5862605193216 bytes (5.9 TB) copied, 8141.34 s, 720 MB/s (пока их 24)
- 1 поток - 10104413880320 bytes (10 TB) copied, 9822.86 s, 1.0 GB/s
- 2 потока - 16951939170304 bytes (17 TB) copied, 17398.4 s, 974 MB/s
- 4 потока - 10740585988096 bytes (11 TB) copied, 7771.81 s, 1.4 GB/s
- 6 потоков - 37457503453184 bytes (37 TB) copied, 27914.8 s, 1.3 GB/s
- 8 потоков - 20083290144768 bytes (20 TB) copied, 14405.3 s, 1.4 GB/s
- 10 потоков - 13290862280704 bytes (13 TB) copied, 9638.1 s, 1.4 GB/s
- 12 потоков - 18429180379136 bytes (18 TB) copied, 15934.9 s, 1.2 GB/s
- 16 потоков - 20072395440128 bytes (20 TB) copied, 22512.1 s, 892 MB/s
- 20 потоков - 19661230964736 bytes (20 TB) copied, 24707.8 s, 796 MB/s (пока их 16)
- 24 потока - 8341583560704 bytes (8.3 TB) copied, 9555.3 s, 873 MB/s (пока их 16)
- 32 потока - 5574189121536 bytes (5.6 TB) copied, 7060.46 s, 789 MB/s (пока их 24)
Вывод: при восстановлении малым количеством потоков необходимо включать кеширование и предварительное чтение.

XFS — высокопроизводительная журналируемая файловая система, созданная Silicon Graphics, Inc. XFS особенно хорошо справляется с параллельным вводом-выводом благодаря структуре на основе заголовков для групп (allocation groups), что обеспечивает исключительную масштабируемость потоков ввода-вывода, пропускной способности файловой системы, размера файлов и файловой системы при работе с несколькими устройствами хранения.

Contents

Установка

Установите пакет xfsprogs для получения утилит XFS в пространстве пользователя. Данный пакет содержит средства, необходимые для управления файловой системой XFS.

Повреждение данных

В случае повреждения данных по какой-либо причине придётся восстанавливать файловую систему вручную.

Восстановление файловой системы XFS

Сначала размонтируйте файловую систему XFS.

После размонтирования запустите утилиту xfs_repair(8) .

Проверка метаданных "на лету" (scrub)
Важно: Эта программа является экспериментальной, соответственно, её поведение и интерфейс могут измениться в любое время, см. xfs_scrub(8) .
xfs_scrub запрашивает ядро очистить (англ. scrub) все объекты метаданных в XFS.Записи метаданных сканируются на очевидно ошибочные значения, после чего перекрёстно ссылаются на остальные метаданные. Это делается для того, чтобы иметь достаточно уверенности в целостности всей файловой системы, анализируя отдельные записи метаданных на фоне остальных метаданных в файловой системе. Повреждённые метаданные можно восстановить из других метаданных при наличии неповреждённых избыточных структур данных.

Включите и запустите xfs_scrub_all.timer для периодической проверки метаданных всех файловых систем XFS "на лету".
Примечание: Для удобства, можно отредактировать xfs_scrub_all.timer : таймер выполняется каждое воскресенье в 3:10 и сразу же запускается, если последний запуск был пропущен (например, так как система была выключена).
Целостность

В xfsprogs 3.2.0 появился новый дисковый (англ. on-disk) формат (v5), включающий в себя схему контрольных сумм метаданных — Self-Describing Metadata. Она основывается на CRC32 и обеспечивает, к примеру, дополнительную защиту от повреждения метаданных при непредвиденном отключении электропитания. Контрольная сумма включена по умолчанию начиная с xfsprogs 3.2.3. Если требуется монтируемый для чтения-записи раздел XFS на более старом ядре, данная функция легко отключается с помощью параметра -m crc=0 при вызове mkfs.xfs(8) .

Дисковый (англ. on-disk) формат XFS v5 считается стабильным для промышленной эксплуатации начиная с ядра Linux 3.15.
Примечание: В отличие от Btrfs и ZFS (англ.), контрольная сумма CRC32 применяется только к метаданным, а не к фактическим данным.
Администрирование

Изменение размера
Примечание: На данный момент XFS не поддерживает уменьшение размера ФС.
XFS позволяет изменять размер файловой системы "на лету". Достаточно выполнить xfs_growfs с указанием точки монтирования, что расширит файловую систему до максимально возможного размера.

Производительность

Просто создайте файловую систему XFS, чтобы достичь оптимальной скорости:

Смотрите также xfs(5) для получения информации о доступных параметрах монтирования.

Размер и ширина полосы (stripe)

Если файловая система будет использоваться на чередующемся RAID-массиве, можно значительно повысить скорость, указав размер полосы (англ. stripe) в команде mkfs.xfs(8) .

XFS иногда определяет "геометрию" программного RAID-массива, но если она изменяется или используется аппаратный RAID, то см. статью "How to calculate the correct sunit,swidth values for optimal performance" (англ.).

Время доступа

В некоторых файловых системах можно повысить производительность, добавив параметр монтирования noatime в файле /etc/fstab . Для XFS стандартным поведением atime является relatime , которое почти не имеет накладных расходов по сравнению с noatime, но при этом сохраняет нормальные значения atime. Все файловые системы Linux теперь используют это в качестве значения по умолчанию (примерно с версии 2.6.30), но XFS использует relatime-поведение с 2006 года, поэтому нет никакой необходимости использовать noatime по соображениям производительности.

Кроме того, noatime подразумевает nodiratime , поэтому нет необходимости указывать nodiratime при уже заданном noatime.

Дефрагментация

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

xfs_fsr(8) улучшает организацию смонтированных файловых систем. Алгоритм реорганизации работает с одним файлом за раз, сжимая или улучшая размещение экстентов файла (последовательных блоков данных файла).

Проверка уровня фрагментации

Проверить уровень фрагментации в данный момент можно следующей командой:

Выполнение дефрагментации

Используйте команду xfs_fsr(8) , чтобы начать дефрагментацию:

B-дерево со свободными inode-ами

Начиная с Linux 3.16, в XFS появилось B-дерево для отслеживания свободных inode, что равноценно существующему B-дереву для распределения индексных дескрипторов, за исключением того, что отслеживаются inode-блоки по крайней мере с одним свободным inode. Это делается для того, чтобы ускорить поиск свободных inode-кластеров при распределении inode. Также это повышает производительность старых файловых систем, например, спустя месяцы или годы после добавления и удаления миллионов файлов на файловой системе. Использование этой функции не влияет на общий уровень надёжности ФС или возможность восстановления.

Данная функция основывается на новом дисковом (on-disk) формате XFS v5, который считается стабильным для промышленной эксплуатации начиная с ядра Linux 3.15. Она не изменяет существующие дисковые структуры, но добавляет новую, которая должна оставаться целостной в B-дереве для отслеживания свободных inode. По этой же причине более старые версии ядра монтируют файловые системы с B-деревом свободных inode только в режиме для чтения.

Также данная функция включена по умолчанию начиная с xfsprogs 3.2.3. Если требуется возможность записи на файловую систему при использовании более старого ядра, отключите её с помощью параметра finobt=0 при форматировании XFS-раздела. crc=0 указывается вместе с предыдущим параметром.

или короче ( finobt зависит от crc )

Внешний журнал XFS

Использование внешнего лога (журнала метаданных), например, на SSD (Русский), может улучшить производительность [1]. См. mkfs.xfs(8) для получения информации о параметре logdev .

Укажите опцию -l logdev=device,size=size команде mkfs.xfs для резервации внешнего журнала определённого размера при создании файловой системы XFS. Если пропустить параметр size , размер журнала будет зависеть от размера ФС. Укажите опцию -o logdev=device команде mount для монтирования XFS с использованием внешнего журнала.

Интервал синхронизации

В XFS существует отдельная переменная sysctl для настройки интервала обратной записи (англ. writeback interval). По умолчанию в Arch используется значение "3000". Возможно также задать и большее значение, однако стоит учитывать, что слишком большое значение может привести к потери данных в некоторых случаях:

Решение проблем

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

Параметры монтирования XFS ( uquota , gquota , prjquota и т.д.) не выполняются во время повторного монтирования файловой системы. Чтобы включить квоту корневой файловой системы, параметр монтирования должен быть передан initramfs как параметр ядра rootflags= . Впоследствии его не следует указывать среди параметров монтирования в /etc/fstab для корневой ( / ) файловой системы.

xfs_scrub_all отказывается работать, если пользователь "nobody" не может получить доступ к точке монтирования

При запуске xfs_scrub_all также запускается [email protected] для каждой примонтированной файловой системы XFS. Данная служба запускается от пользователя nobody и соответственно, если nobody не может перейти в директорию, команда завершится со следующей ошибкой:

Чтобы разрешить запуск службы, измените разрешения точки монтирования таким образом, чтобы у пользователя nobody были права на выполнение.

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

Способ организации файловой системы в Linux

В качестве способа повышения эффективности ОС, в Linux применяется следующая модель файловой системы:

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

Ядро Linux поддерживает различные типы файловых систем (ext3, ext4, ReiserFS, Btrfs, XFS и многие другие). На сегодняшний день наиболее часто используемой файловой системой является ext4, поэтому в данной статье основной упор будет сделан именно на нее.

Примечание: В Linux практически все объекты представлены в виде файлов (например, каталоги, принтеры, разделы диска, устройства и т.д.). Это делает еще более важным изучение того, как работает файловая система Linux.

Эволюция файловой системы ext в Linux

Давайте детально рассмотрим эволюцию файловой системы ext в Linux:

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

Файловая система Minix — это первая файловая система, являющаяся прообразом современных файловых систем в Linux, которая была представлена в 1987 году Эндрю С. Таненбаумом в составе одноименной ОС Minix.

Операционная система Minix и её файловая система использовались в виде наглядного пособия для студентов, изучающих основы строения ОС (одним из таких студентов был сам Линус Торвальдс). Из-за того, что Minix была, прежде всего, учебной системой, её файловая система обладала множеством недостатков: производительность файловой системы оставляла желать лучшего; длина имени файла была ограничена 14 символами, а размер разделов — 64 МБ. Для сравнения, жесткие диски того времени имели размер вплоть до 140 МБ.

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

Хотя ext и удалось решить проблемы, присутствовавшие в файловой системе Minix, у нее был один серьезный недостаток — временная метка. Сейчас, когда каждый файл в Linux имеет три временные метки (доступа к файлу, изменения содержимого файла, изменения свойств и метаданных файла (например, разрешений)), файловая система ext поддерживала только одну временную метку.

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

В январе 1993 года, менее чем через год после выхода ext, Реми Кард разрабатывает новую файловую систему — ext2.

В ext2 были расширены функциональные возможности ext:

увеличена производительность файловой системы;

данные файлов хранились в блоках данных одинаковой длины;

поддерживался максимальный размер файла в 2 тебибайта;

длина имени файла была ограничена 255 байтами (а не количеством символов, как раньше).

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

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

Система ext2 использовалась по большей части до начала 2000-х годов, когда была представлена файловая система ext3.

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

В ноябре 2001 года, благодаря усилиям программиста Стивена Твиди, вместе с релизом ядра Linux 2.4.15 увидела свет и новая файловая система — ext3.

Файловая система ext3 — это улучшенная версия файловой системы ext2, в которой появилась возможность ведения логов. Она, как и ext2, поддерживает файлы размером в 2 тебибайта, а имена файлов ограничены 255 байтами.

Ядро Linux поддерживает три уровня ведения логов:

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

Ordered — процесс сохранения данных выполняется в определенном порядке: сначала в лог-файл записываются метаданные, затем содержимое файла записывается в основную файловую систему и уже тогда метаданные соединяются с основной файловой системой. В случае сбоя, основная файловая система не будет повреждена; риску повреждения подвергаются только те файлы, которые находятся во время сбоя непосредственно в процессе записи.

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

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

Файловая система ext4 была представлена в октябре 2008 года вместе с ядром Linux 2.6.28. Она поддерживает максимальный размер файла в 16 тебибайт и ограничивает максимальную длину имени файла 255 байтами.

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

Давайте рассмотрим основной функционал файловой системы ext4:

Обратная совместимость. Файловая система ext4 поддерживает обратную совместимость с файловыми системами ext3 и ext2. Дополнительной функцией является автоматическое монтирование файловой системы ext3 в режиме ext3 с помощью драйвера ext4.

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

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

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

Неограниченное количество подкаталогов. Ядро Linux версии 2.6.23 поддерживает неограниченное количество подкаталогов. Файловая система ext4 ввела древовидную структуру данных HTree, чтобы избежать снижения производительности. HTree представляет собой специализированную версию B-дерева.

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

Быстрая проверка файловой системы. Файловая система ext4 помечает нераспределенные группы блоков. Время, необходимое для выполнения команды проверки диска fsck , значительно сокращается, поскольку отмеченные группы пропускаются. Это повышает общую производительность.

Онлайн-дефрагментация. Фрагментация диска приводит к снижению производительности файловой системы, что было серьезной проблемой для ext2 и ext3. Файловая система ext4 поддерживает утилиту e4defrag, которая позволяет пользователям дефрагментировать отдельные файлы или всю файловую систему.

Ограничения файловой системы ext4

Хотя файловая система ext4 считается лучшей файловой системой для дистрибутивов Linux, есть несколько ограничений, которые следует учитывать в вашей дальнейшей работе:

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

Максимальный размер тома установлен в 1 эксбибайт. Однако файловая система не может обрабатывать более 100 тебибайт данных без значительной потери производительности и увеличения фрагментации диска.

Альтернативные файловые системы

Существует несколько альтернативных файловых систем, поддерживаемых ядром Linux.

XFS — это 64-разрядная файловая система, которая впервые была представлена в 1994 году и встроена в ядро Linux с 2001 года. XFS поддерживает максимальный размер файла в 8 эксбибайт и ограничивает длину имени файла 255 байтами. Она поддерживает ведение логов и, как и ext4, сохраняет изменения в лог-файле до того, как они будут зафиксированы в основной файловой системе. Это снижает вероятность повреждения файлов.

Данные структурированы в виде B + -деревьев, что обеспечивает эффективное распределение пространства и, следовательно, повышение производительности.

Основным недостатком этой системы является сложный процесс изменения размера существующей файловой системы XFS.

OpenZFS

OpenZFS — это платформа, которая объединяет функционал традиционных файловых систем и диспетчера томов. Впервые была представлена в 2013 году. OpenZFS поддерживает максимальный размер файла в 16 эксбибайт и ограничивает максимальную длину имени файла 255 символами. В качестве особенностей данной системы можно выделить защиту от повреждения данных, шифрование данных, поддержку накопителей увеличенного объема, копирование при записи и RAID-Z.

Основным недостатком OpenZFS является юридическая несовместимость между лицензиями CDDL (OpenZFS) и GPL (ядро Linux). Эта проблема решается путем компиляции и загрузки кода ZFS в ядро Linux.

Btrfs

Некоторые особенности Btrfs включают в себя:

добавление и удаление блочных устройств в режиме онлайн;

настраиваемое для каждого файла или тома сжатие;

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

ReiserFS

ReiserFS — это альтернатива файловой системе ext3, которая обладает улучшенной производительностью и расширенным функционалом. Ранее, ReiserFS использовалась в качестве файловой системы по умолчанию в SUSE Linux. ReiserFS поддерживает динамическое изменение размеров файловой системы. К недостаткам можно отнести относительно низкую производительность.

Примечание: Такие файловые системы, как NTFS, FAT и HFS могут использоваться в Linux, но корневая файловая система Linux на них не устанавливается, поскольку они для этого не предназначены. Swap — это файл подкачки, служащий источником дополнительной памяти в тех случаях, когда для выполнения программы требуется больше оперативной памяти, чем имеется в компьютере, — он не является отдельной файловой системой.

Как узнать, какая у меня файловая система?

Способ №1: Использование команды df

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

$ df -Th | grep "^/dev"

Как вы можете видеть, у меня используется файловая система ext4 (см. раздел /dev/sda1).

Примечание: Имена дисков в Linux расположены в алфавитном порядке. /dev/sda — это первый жесткий диск (основной), /dev/sdb — второй и т.д. Цифры относятся к разделам, поэтому /dev/sda1 — это первый раздел первого диска.

Способ №2: Использование команды fsck

Команда fsck применяется для проверки и, при необходимости, восстановления файловых систем Linux. При этом она также может отображать и тип файловой системы на указанных разделах диска, например:

Способ №3: Использование команды lsblk

Команда lsblk отображает информацию о блочных устройствах. Добавив опцию -f , мы также получим и информацию о типе файловой системе:

Способ №4: Использование команды mount

Команда mount применяется для монтирования файловой системы в Linux. Её также можно использовать для монтирования ISO-образа, удаленной файловой системы Linux и многого другого. Чтобы узнать тип файловой системы, используйте следующую комбинацию:

Всем привет! Изучаю сейчас XFS (и немного ZFS). Про XFS прочитал, что она гораздо лучше подходит для работы с большими файлами и при больших нагрузках. То есть оптимальна для серверов. Но из недостатков - не умеет в уменьшение размера. Знаю что в RHEL 7 она по дефолту. Если с ZFS более менее понятно, то по XFS у меня есть такие вопросы:

1) насколько полезна она будет на десктопе, вместо ext4?
2) стоит ли разворачивать поверх неё LVM? Имеется ввиду подводные камни. Допустим у меня RAID1 с XFS.
3) как ведёт себя XFS на SSD?

Собственно, интересует именно практический опыт. Теорию могу и в интернете почитать.

1) насколько полезна она будет на десктопе, вместо ext4?

Я использовал, прикола не понял. Теперь использую Btrfs, т.к. она фичастая.

2) стоит ли разворачивать поверх неё LVM? Имеется ввиду подводные камни. Допустим у меня RAID1 с XFS.

Сможешь тогда уменьшать раздел с XFS, если включишь LVM Thin Provisioning. Но вообще Thin Provisioning тормозит.

Я точно теорию не знаю, но с труктура XFS основана на B-деревьях, а для SSD это очень даже хорошо. Discard есть, на SSD работает не хуже других ФС.

А вот использовать LVM на SSD не советую. У меня плохой опыт — LVM очень сильно тормозит загрузку.

Вообще при описанной схеме подводных камней быть не должно. Сам использовал такой пирог: MBR раздел -> LVM -> LUKS -> XFS — полет нормальный. Но в итоге отказался от всей фигни и просто раскатываю Btrfs поверх LUKS (с отдельным /boot и swap).

1) насколько полезна она будет на десктопе, вместо ext4?

Собственно, интересует именно практический опыт.

Когда я пробовал XFS пару лет назад, после отключения питания (внезапного), она мне испортила раздел с файлами. Погуглив, это оказалось нормой для данной ФС.

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

Когда я пробовал XFS пару лет назад, после отключения питания (внезапного), она мне испортила раздел с файлами. Погуглив, это оказалось нормой для данной ФС.
Не знаю как сейчас, может исправили что, но испытывать судьбу второй раз не хочется, ext4 наше все.

У меня та же фигня была, после того как на вторую версию XFS обновился. Только я и второй раз решил попробовать — оба раза раздел рассыпался.

Но на серверах все нормально работает, даже после сбоев питания (хотя сбоев не много).
Black_Roland ★★★★ ( 02.08.15 11:19:11 )
Последнее исправление: Black_Roland 02.08.15 11:19:34 (всего исправлений: 1)

Write barrier support is enabled by default in XFS since kernel version 2.6.17.

Быстро время летит.

после того как на вторую версию XFS обновился
вторую версию

Что ты имеешь в виду?

Да не заливай, я тогда еще с линуксом не был знаком.

Это где-то 2011-2012 год.

Возможно я с пятой путаю.

Использую xfs везде с времен когда ext2(3) не умел увеличиваться в размерах онлайн, потом появился патч от redhat (ext2online), потом resize2fs научился online resize ext2(3), но это годы на xfs и до сих пор.

стоит ли разворачивать поверх неё LVM? Имеется ввиду подводные камни. Допустим у меня RAID1 с XFS.

Много где есть mdadm(raid1)->lvm->xfs, никаких подводных камней, такой конфиг настолько распространен, а код всего этого дела настолько старый и отлаженный, что нарваться на непредвиденные проблемы практически невозможно.

Сейчас у меня основная ФС. На старых винтах еще осталась reiserfs, но xfs работает значительно быстрее как с крупными так и с мелкими файлами (на райзере хвостовая упаковка пашет). Еще и на сервере тоже xfs стоит. Все выключения света восприняла нормально, подымается после такого дауна быстрее, reiserfs может достаточно долго возюкатся.

С ext4 вообще не захотел связываться. Как оказалось не зря. Поспрашивал админа на работе, на серверах чаще всего грохается ext4. Сейчас тоже переходят на xfs.

насколько полезна она будет на десктопе, вместо ext4?

SLE и RH перешли по умолчанию на XFS для данных. Но тут скорее мотивация в том что разработка EXT4 прекратилась (только исправления ошибок), XFS же продолжают развивать.

ну значит ССЗБ что использовал без barrier=on. Я её юзал на машине без ИБП, свет за 3 года выключали раз 40 - раздел живой, как и все данные на нём.

А без этой опции она, бесспорно, еще быстрее, но малейшее пропадание питания - русская рулетка с револьвером где заряжено 5 патронов в барабане из 6

1) насколько полезна она будет на десктопе, вместо ext4?

В корень бессмысленно. В хомяк — смотря что в хомяке. Под торренты — хорошо себя покажет. Юзаю под торренты и хранение больших файлов (кино, дистрибутивы игр и подобное). Для торрентов лучше, чем ext4. Для остального я лично разницы никакой не замечал.

Там не будет её преимуществ, то есть смысла нет. На SSD лучше ext4. Либо F2FS, но её я не пробовал, он вроде пока сыровата.

ЕМНИП оно включено по дефолту.

Дважды ломалась xfs в виртуалках с центосью семёркой, починить ни разу не смог.
В первый раз у меня был доступ к железной ноде, удалось вытащить /etc от виртуалки, а /usr оказался пустым, например. А во второй раз якобы произошёл сбой контроллера на сервере у хостера, но тогда у меня уже бэкапы были, просто-напросто пересетапил виртуалку и накатил их.
Так что xfs не советую.

Нормально всё, раздел 20тб уже лет 6 на хфс пашет 24х7, выключался по всякому, никаких глюков.

У нормальных SSD есть конденсатор

Да я не так зажиточно жил лет 3-4 назад, что бы использовать SSD.

1. При наличии 1 000 000+ файлов или 16ТБ+ разделов очень полезна. При наличии постоянной высокой нагрузки на ФС (торрент + работа с видео на одном диске/массиве) полезна.

2. Как уже писали выше mdadm RAID + LVM + XFS это один из золотых стандартов. Связка проверенная временем и кучей серьезных проектов.

3. Замечательно. Хочешь TRIM её делаешь через discard, а хочешь вручную. Есть пару параметров которые могут увеличить её скорость на SSD в некоторых задачах, но это предмет отдельного разговора.

З.Ы. У XFS на сегодня уже есть 5 версий, последняя пятая поддерживается с ядра 3.16, если мне не отшибает память. Задается версия при создании ФС в утилите mkfs.xfs, там же можно задать еще пару полезных параметров, которые после создания добавить уже будет невозможно, поэтому серьезно подойди к изучению параметров mkfs.xfs

Там работа с атрибутами файлов отлична от ext, в связи с чем возможны интересные феномены. например, игра Natural Selection 2 на xfs не работает

xfsprogs начиная с 3.2.3 по умолчанию создаёт пятый формат с crc и finobt.
Вот только даже до стабильного арча оно пока не доехало, а уже 3.2.4 выпустили.
d ★★★★ ( 02.08.15 15:58:33 )
Последнее исправление: d 02.08.15 16:00:05 (всего исправлений: 1)
На больших файлах и многопоточной нагрузке, судя по тестам, XFS хороша. Но особенного смысла использовать на десктопе не вижу. Не то, чтобы я не рекомендовал XFS по сравнению с ext4, просто не вижу в таком случае сильных преимуществ. Косяков со свободным местом нет ни там, ни там, скорость работы на относительно (скажем, не более 5-7 лет) для десктопа вполне нормальная. Так что:

1) насколько полезна она будет на десктопе, вместо ext4?

Принципиальных отличий (для десктопа) нет.

2) стоит ли разворачивать поверх неё LVM? Имеется ввиду подводные камни. Допустим у меня RAID1 с XFS.

Хз, LVM давно не юзал, сомневаюсь в его полезности для десктопа. На RAID1 вроде потерь по скорости больших нет. Я когда-то немного поисследовал этот вопрос, но многое забыл, лучше посмотри тесты.

Говорят, что нормально. Поддержка TRIM в наличии.

Что, дружок, вброс не удался?
Упоминание zfs не привело к очередному срачу?

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