XFS: различия между версиями

Материал из sysadm
Перейти к навигации Перейти к поиску
 
(не показано 15 промежуточных версий этого же участника)
Строка 1: Строка 1:
 +
 +
'''Особенности'''
 +
* высокая производительность при работе с большими файлами
 +
** есть возможность для оптимизации под геометрию RAID
 +
** есть возможность оптимизации выделения места экстентами (непрерывная последовательность блоков)
 +
* нет возможности уменьшения размера файловой системы
  
 
'''Форматирование'''
 
'''Форматирование'''
Строка 7: Строка 13:
 
# xfs поддерживает bsize от 512b до 64K
 
# xfs поддерживает bsize от 512b до 64K
 
# при bsize менее 1024b не поддерживается CRC
 
# при bsize менее 1024b не поддерживается CRC
# форматирование с указанием bsize
+
# форматирование с указанием bsize, на старых ядрах ткакя ФС может не монтироваться
 
mkfs.xfs -b size=64K /path/to/dev
 
mkfs.xfs -b size=64K /path/to/dev
  
 
# утилита blkid отображает параметр BLOCK_SIZE который соответствует размеру сектора блочного устройства sectsz, но не блока файловой системы bsize
 
# утилита blkid отображает параметр BLOCK_SIZE который соответствует размеру сектора блочного устройства sectsz, но не блока файловой системы bsize
 +
 +
# форматирование с оптимизацией под LVM RAID (не проверено)
 +
# размер stripe unit = 32k, количество stripe unit в страйпе = 6
 +
# ??? по умолчанию параметры LVM RAID не определяются автоматом?
 +
mkfs.xfs -d su=32k,sw=6 /dev/vg0/lv1
 +
 +
</pre>
 +
 +
'''Информация о файловой системе'''
 +
<pre>
 +
xfs_info
 +
 +
# sectsz - размер блока блочного устройства
 +
# bsize  - размер блока файловой системы
 +
# extsz  - ???
 +
 +
# crc=1    - включена CRC проверка
 +
# sparse=1 - включена поддержка sparse
 +
 +
</pre>
 +
 +
'''Изменение размера файловой системы'''
 
<pre>
 
<pre>
 +
# уменьшение размера невозможно
 +
 +
# увеличение размера
 +
xfs_growfs -d /mount/point
 +
</pre>
 +
 +
'''Изменение параметров файловой системы'''
 +
</pre>
 +
xfs_admin
 +
</pre>
  
 
'''Дефрагментация'''
 
'''Дефрагментация'''
  
 
* дефрагментация имеет смысл только для HDD, на SSD она не повышает производительность и приводит к лишнему износу устройства
 
* дефрагментация имеет смысл только для HDD, на SSD она не повышает производительность и приводит к лишнему износу устройства
* архитектура XFS позволяет избегать лишней фрагментации и в большинстве случаев не имеет смысла часто выполнять дефрагментацию
+
* архитектура XFS позволяет избегать лишней фрагментации и в большинстве случаев либо не нужна, либо нужна не часто
 
* в XFS фрагментация может возникать если файлы часто создаются и удаляются
 
* в XFS фрагментация может возникать если файлы часто создаются и удаляются
  
Строка 28: Строка 66:
 
xfs_fsr /path/to/file
 
xfs_fsr /path/to/file
  
# дефрагментация всех смонтированных файловых систем
+
# дефрагментация всех устройств перечисленных в /etc/mtab
 
xfs_fsr
 
xfs_fsr
 +
 +
</pre>
 +
 +
'''Backup и Restore'''
 +
<pre>
 +
# дамп файловой системы
 +
xfsdump -f /path/to/file.tar /path/to/mountpoint
 +
 +
# восстановление файловой системы
 +
# предварительно необходимо создать и смонтировать новую файловую систему
 +
xfsrestore -f /path/to/backup.tar /path/to/mountpoint
 +
 +
# восстановление в интерактивном режиме с возможностью выбора отдельных каталогов для восстановления
 +
xfsrestore -i -f /path/to/backup.tar
 +
 +
# похоже эти утилиты просто выполняют tar (предположение)
 +
 +
</pre>
 +
 +
= Важные особенности XFS =
 +
 +
<pre>
 +
При работе с XFS необходимо учитывать следующее
 +
 +
* Для распараллеливания дисковых операций XFS делит том на несколько AG (Allocation Group)
 +
* Оптимально когда это количество равно количеству потоков/ядер
 +
  * по умолчанию, mkfs.xfs всегда создает 4 AG (ну или почти всегда)
 +
  * меньше 4-х это плохо потому что мало распараллеливания
 +
  * сильны больше количества потоков плохо, потому что будет перебор всех
 +
* Размер AG определяется при форматировании и потом его нельзя изменить, только заново отформатировать
 +
* Все AG одного размера, только последняя может быть меньше, если размер тома не кратен размеру AG
 +
  * по расходу места оптимально когда размер тома кратен размеру AG
 +
  * размер структур зависит от размера AG, у больших много у мелких мало, в сумме примерно одинаково
 +
  * если при большом AG, том ему не кратен, то полезного места будет меньше
 +
* У каждой AG своя независимая структура и свои метаданные, объединяет все небольшой суперблок в начале
 +
* При расширении XFS, добавляет новые AG, соответственно их количество растет и может стать не оптимальным
 +
* Самый плохой сценарий, когда вы создаете том 10 ГиБ и расширяете его до 2.5 ТиБ, получите 1000 AG по 2.5 ГиБ
 +
* Нормальный сценарий
 +
  * сразу определяем какой размер у нас будет максимальный и как у нас будут расти ядра
 +
  * задаем размер AG так чтобы по достижении максимального размера их количество было не сильно больше количества ядер
 +
  * Например, у нас 8 ядер, в перспективе 16.
 +
    - размер AG задаем 128 ГиБ
 +
    - создаем том на 4 AG, 512 ГиБ, со временем можем расширить до 1 ТиБ
 +
    - дальше создаем следующий том
 +
    - если пришло время добавить ядер до 12, то можем расширять все тома до 1.5 ТиБ
 +
    - если пришло время добавить ядер до 16, то можем расширять до 2 ТиБ
 +
 +
# пример задания размера AG
 +
mkfs.xfs -d agsize=128g /path/to/device
  
 
</pre>
 
</pre>

Текущая версия на 20:07, 13 ноября 2025

Особенности

  • высокая производительность при работе с большими файлами
    • есть возможность для оптимизации под геометрию RAID
    • есть возможность оптимизации выделения места экстентами (непрерывная последовательность блоков)
  • нет возможности уменьшения размера файловой системы

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

# по умолчанию, bsize=4K
mkfs.xfs /path/to/dev

# xfs поддерживает bsize от 512b до 64K
# при bsize менее 1024b не поддерживается CRC
# форматирование с указанием bsize, на старых ядрах ткакя ФС может не монтироваться
mkfs.xfs -b size=64K /path/to/dev

# утилита blkid отображает параметр BLOCK_SIZE который соответствует размеру сектора блочного устройства sectsz, но не блока файловой системы bsize

# форматирование с оптимизацией под LVM RAID (не проверено)
# размер stripe unit = 32k, количество stripe unit в страйпе = 6
# ??? по умолчанию параметры LVM RAID не определяются автоматом?
mkfs.xfs -d su=32k,sw=6 /dev/vg0/lv1

Информация о файловой системе

xfs_info

# sectsz - размер блока блочного устройства
# bsize  - размер блока файловой системы
# extsz  - ???

# crc=1    - включена CRC проверка
# sparse=1 - включена поддержка sparse

Изменение размера файловой системы

# уменьшение размера невозможно

# увеличение размера
xfs_growfs -d /mount/point

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

xfs_admin

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

  • дефрагментация имеет смысл только для HDD, на SSD она не повышает производительность и приводит к лишнему износу устройства
  • архитектура XFS позволяет избегать лишней фрагментации и в большинстве случаев либо не нужна, либо нужна не часто
  • в XFS фрагментация может возникать если файлы часто создаются и удаляются
# опретеделение текущего уровня фрагментации
xfs_db -c frag -r /dev/sdX#

# дефрагментация
xfs_fsr /path/to/dev
xfs_fsr /mount/point
xfs_fsr /path/to/file

# дефрагментация всех устройств перечисленных в /etc/mtab
xfs_fsr

Backup и Restore

# дамп файловой системы
xfsdump -f /path/to/file.tar /path/to/mountpoint

# восстановление файловой системы
# предварительно необходимо создать и смонтировать новую файловую систему
xfsrestore -f /path/to/backup.tar /path/to/mountpoint

# восстановление в интерактивном режиме с возможностью выбора отдельных каталогов для восстановления
xfsrestore -i -f /path/to/backup.tar

# похоже эти утилиты просто выполняют tar (предположение)

Важные особенности XFS

При работе с XFS необходимо учитывать следующее

* Для распараллеливания дисковых операций XFS делит том на несколько AG (Allocation Group)
* Оптимально когда это количество равно количеству потоков/ядер
  * по умолчанию, mkfs.xfs всегда создает 4 AG (ну или почти всегда)
  * меньше 4-х это плохо потому что мало распараллеливания
  * сильны больше количества потоков плохо, потому что будет перебор всех
* Размер AG определяется при форматировании и потом его нельзя изменить, только заново отформатировать
* Все AG одного размера, только последняя может быть меньше, если размер тома не кратен размеру AG
  * по расходу места оптимально когда размер тома кратен размеру AG
  * размер структур зависит от размера AG, у больших много у мелких мало, в сумме примерно одинаково
  * если при большом AG, том ему не кратен, то полезного места будет меньше
* У каждой AG своя независимая структура и свои метаданные, объединяет все небольшой суперблок в начале
* При расширении XFS, добавляет новые AG, соответственно их количество растет и может стать не оптимальным
* Самый плохой сценарий, когда вы создаете том 10 ГиБ и расширяете его до 2.5 ТиБ, получите 1000 AG по 2.5 ГиБ
* Нормальный сценарий
  * сразу определяем какой размер у нас будет максимальный и как у нас будут расти ядра
  * задаем размер AG так чтобы по достижении максимального размера их количество было не сильно больше количества ядер
  * Например, у нас 8 ядер, в перспективе 16.
    - размер AG задаем 128 ГиБ
    - создаем том на 4 AG, 512 ГиБ, со временем можем расширить до 1 ТиБ
    - дальше создаем следующий том
    - если пришло время добавить ядер до 12, то можем расширять все тома до 1.5 ТиБ
    - если пришло время добавить ядер до 16, то можем расширять до 2 ТиБ

# пример задания размера AG
mkfs.xfs -d agsize=128g /path/to/device