The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Оценка эффективности работы fsck на гигантских разделах XFS и Ext4

04.02.2012 21:53

Представлены результаты оценки эффективности работы утилиты fsck при проверке файловых систем XFS и Ext4. Особенностью проведённых тестов является размер проверяемых данных - для каждой из ФС эксперименты проводились на разделе размером 72 Тб: DDN SFA10K-X из 590 дисков по 450 Гб, на базе которых создано 23 RAID-6 по 10 дисков в каждом, которые объединены в единый раздел при помощи mdadm. Для заполнения раздела на 50% использовалась утилита fs_mark, позволяющая сгенерировать структуру каталогов с наполненными случайными данными файлами (в разных тестах создано 100-400 млн файлов).

Результаты:

Размер ФС в Тб Число файлов (млн) Время выполнения "xfs_repair -v" для XFS (сек) Время выполнения "fsck -pfFt" для Ext4 (сек)
72
105
1629
3193
72
51
534
1811
72
10.2
161
972
38
105
710
3372
38
51
266
1358
38
10.2
131
470

Отдельно было проведено несколько дополнительных тестов для файловой системы XFS. На проверку 415 млн файлов на файловой системе XFS ушло более 3 часов. Выполнение fsck для раздела с фрагментированным наполнением из 105 тысяч файлов, созданных в результате 15 этапов наполнения, было затрачено около 11 минут. Проверка тех же 105 тысяч файлов, созданных только в директории первого уровня, заняла 27 минут.

  1. Главная ссылка к новости (http://www.enterprisestoragefo...)
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/32994-xfs
Ключевые слова: xfs, ext4, fsck
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (43) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 22:09, 04/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Ext4
    > 72 Тб

    это когда появилось?

     
     
  • 2.2, StreamThreader (ok), 22:11, 04/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А в чём проблема то?
     
     
  • 3.5, Аноним (-), 22:41, 04/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    еще недавно было только 16
     
     
  • 4.6, pumainthailand.com (?), 22:57, 04/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    ПО моему это было ограничение софта для создания разделов, а не самой файловой системы.
     
     
  • 5.9, Аноним (-), 00:30, 05/02/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > ПО моему это было ограничение софта для создания разделов, а не самой
    > файловой системы.

    Именно так, mke2fs не умел создавать тома больше, но сама ФС вполне умела работать и с более крупными томами.

     
  • 2.8, Stax (ok), 23:53, 04/02/2012 [^] [^^] [^^^] [ответить]  
  • +4 +/
    В ноябре были выпущены e2fsprogs, в которых сделали создание систем >16 Тб - http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.42
     

  • 1.7, Anonus (?), 23:07, 04/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    лучше бы время fsmark показали
     
     
  • 2.14, anonymous (??), 09:04, 05/02/2012 [^] [^^] [^^^] [ответить]  
  • +5 +/
    А в обсуждении скорости работы xfs Благородный Дон напишет "лучше бы время fsck показали".
     
     
  • 3.32, Anonus (?), 01:37, 06/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    нет
     

  • 1.10, pavlinux (ok), 04:24, 05/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > XFS -- rw,noatime,attr2,nobarrier,inode64,noquota

    Пля, сто тыщь мильонов раз говорил, для attr2 надо специально готовить FS,
    просто /sbin/mkfs.xfs -f /dev/md1 - толку НОЛЬ.
    Могли бы ещё больше разогнать, добавив хотябы mkfs.xfs –i attr=2

    А правильные sunit и swidth вообще творят чудеса.

    ---
    Да и без барьеров это не файловая система, это файловая помойка.

     
     
  • 2.13, John (??), 08:51, 05/02/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Да и без барьеров это не файловая система, это файловая помойка.

    Какие барьеры на software RAID?

     
     
  • 3.17, all_glory_to_the_hypnotoad (ok), 12:35, 05/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    такие же как и везде
     
     
  • 4.20, Аноним (-), 14:58, 05/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    На чём-то сложнее зеркала барьеры не работают.
     
     
  • 5.22, pavlinux (ok), 15:47, 05/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > На чём-то сложнее зеркала барьеры не работают.

    Работают, тока они нафиг не нужны. Видимо данные не совсем крытичные

     
     
  • 6.41, Andrew Kolchoogin (?), 18:41, 06/02/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Барьеры вообще не нужны. Должен быть RAID-контроллер с BBU. Если его нет -- значит, данные некритичные.
     
     
  • 7.45, all_glory_to_the_hypnotoad (ok), 22:04, 06/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    если данные действительно важные, то на контроллере выключают кеш на запись и используют барьеры.
     
  • 2.21, Аноним (-), 15:46, 05/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > А правильные sunit и swidth вообще творят чудеса.

    А разве они автоматом не определяются?

     
     
  • 3.23, pavlinux (ok), 15:49, 05/02/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> А правильные sunit и swidth вообще творят чудеса.
    > А разве они автоматом не определяются?

    Неа. Unix way :)

     
     
  • 4.25, ананим (?), 16:40, 05/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    это ты зря.
    xfs сейчас в автомате очень не плохо создаётся.
     
     
  • 5.42, Аноним (-), 21:44, 06/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > xfs сейчас в автомате очень не плохо создаётся.

    И откуда он должен узнать удобный для рэйда кусок? Рэйдов и их метаданных в природе существует целый легион.

     
     
  • 6.47, ананим (?), 02:51, 08/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >И откуда он должен узнать удобный для рэйда кусок? Рэйдов и их метаданных в природе существует целый легион.

    и что?

     

  • 1.11, Аноним (-), 07:13, 05/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Забыли указать сколько оно памяти жрет в процессе. У меня fsck.xfs на 20ТБ выжрало 44ГБ памяти.
     
     
  • 2.12, phaoost (ok), 08:03, 05/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    это где ж ей столко памяти найти
     
     
  • 3.15, Аноним (-), 09:48, 05/02/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Где-нить рядышком на соседнем НЖМД?
     
  • 3.18, all_glory_to_the_hypnotoad (ok), 12:36, 05/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    нашёл 20 тб хранилище, найдёшь и столько памяти. Для сервера размеры вполне типичные
     
     
  • 4.19, Аноним (-), 12:57, 05/02/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Для сервера чего? Мордокниги? :D:D:D
     
  • 4.24, Stax (ok), 16:23, 05/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ога, да.
    Вот у меня домашнее хранилище:
    $ df -h /mnt/storage/
    Файловая система Размер Использовано  Дост Использовано% Cмонтировано в
    casper:/storage/    22T          12T  9,3T           57% /mnt/storage

    (это 10 трехтерабайтников в raidz2, расшаренных по nfs).

    А где памяти 44 гига взять, когда в low-end серверы на s1156 или s1155 больше 16 не воткнуть? Или вы предлагаете покупать заметно более дорогое железо (там реально скачек раза в 2 на сервер+материнку, чтобы поддержать столько памяти) только ради факта использования xfs?

    Между прочим, полно и других подобных задач, например бэкап-сервер в небольшой огранизации. Место нужно много терабайт, а память не нужна практически совсем - оно же под последовательную запись, изредка бывает что-то нужно последовательно считать, там независимо от объема хранилища 4-8 Гб будет за глаза, и то чисто формально (хватило бы и 2 Гб), потому что меньше как-то нет смысла ставить. А xfs'у 44 гига подавай.. не жирно будет?

     
     
  • 5.26, Аноним (-), 16:48, 05/02/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > (это 10 трехтерабайтников в raidz2, расшаренных по nfs).

    Позвольте узнать, сколько это ваше счастье-то жрет? По самым скромным оценкам, для нормальной работы raidz такого объема нужно гига 64.
    На этом фоне очень странно выглядят придирки к 44 гигам для оффлайновой проверки (а не непрерывной рантаймовой работы).

     
     
  • 6.27, ананим (?), 16:54, 05/02/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >На этом фоне очень странно выглядят придирки

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

     
  • 6.31, Stax (ok), 00:38, 06/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Эээ расскажите, как оценивали :)
    Сейчас 16 гигабайт памяти, они почти все чисто под кэш - раньше было 8, работало тоже хорошо. Сама по себе фс требует копейки, ну сотни мегабайт, возможно; все остальное - это кэш ARC, конечно, чем больше, чем лучше, но это зависит от задачи. Если много случайного чтения, сосредоточенного в определенных кусках диска (скажем, сторейдж для виртуалок), то есть смысл в большом объеме памяти, SSD под кэш и прочее. Но если операции в основном последовательные, как на домашнем NAS или на бэкап-сервере, то паямти много не нужно. На солярке систему под эти нужды можно и на 4 Гб развернуть, работать будет точно так же по скорости - хоть 20 Тб фс, хоть 40. Например, сейчас из 16 гигов на этой системе 11 гигов свободно - ну нет никакого смысла кэшировать последовательные чтения.
    А сам по себе raidz памяти не потребляет. Ему не зачем. Проверка, которая scrub, тоже памяти не требует.

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

    А "придирка" по поводу проверки против рантаймовой работы - это, знаете, совсем не придирка. Вы пойдете добавлять в сервер, где сейчас 8 гигов памяти 40 дополнительных в момент запуска проверки, что ли?

     
     
  • 7.34, Аноним (-), 03:35, 06/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Эээ расскажите, как оценивали :)

    По опыту попыток применения на продакшенах.
    Разумеется, при тестировании мы отнюдь не стремились воспроизвести тепличные условия с последовательным чтением, как вы описываете. Все-таки не путаем винчестеры со стримерами.

    > А "придирка" по поводу проверки против рантаймовой работы - это, знаете, совсем не придирка. Вы пойдете добавлять в сервер, где сейчас 8 гигов памяти 40 дополнительных в момент запуска проверки, что ли?

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

     
  • 5.33, all_glory_to_the_hypnotoad (ok), 02:11, 06/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Между прочим, полно и других подобных задач, например бэкап-сервер в небольшой огранизации. Место нужно много терабайт, а память не нужна практически совсем - оно же под последовательную запись, изредка бывает что-то нужно последовательно считать, там независимо от объема хранилища 4-8 Гб будет за глаза, и то чисто формально (хватило бы и 2 Гб), потому что меньше как-то нет смысла ставить. А xfs'у 44 гига подавай.. не жирно будет?

    Конкретно в этом юз кейсе вы себе придумываете проблему из воздуха. Во-первых, для задач бэкапа и последовательных чтений/записи нужно использовать ленточки, да ещё на таких объёмах. Ну если нет $ на ленточки и есть на массив под бэкапы, то нахрена а) юзать именно xfs и б) делать одну монолитную ФС на десятки Тб? Это же просто идиотизм. Причём, не только для xfs.

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

     

  • 1.16, Аноним (-), 09:51, 05/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    32 Гига ОЗУ не хватило. Пришлось экстренно создавать файл подкачки.
     
     
  • 2.43, Аноним (-), 21:46, 06/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > 32 Гига ОЗУ не хватило.

    А сколько диск был? :)

     

  • 1.30, metallic (ok), 21:31, 05/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    У меня аналогичный конфиг, 90ТБ на XFS (192 диска по 600ГБ, 12 RAID6 по 16 дисков, объединены LVM в страйп)
     
     
  • 2.35, Аноним (-), 03:37, 06/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > У меня аналогичный конфиг, 90ТБ на XFS (192 диска по 600ГБ, 12
    > RAID6 по 16 дисков, объединены LVM в страйп)

    В страйп или просто в линейную группу?

     
     
  • 3.36, metallic (ok), 10:28, 06/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Именно в страйп, в линейной группе не будет прироста производительности.
     
     
  • 4.37, all_glory_to_the_hypnotoad (ok), 11:01, 06/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    на xfs будет. Правда, смотря как её измерять.
     
     
  • 5.38, metallic (ok), 11:02, 06/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > на xfs будет. Правда, смотря как её измерять.

    За счет чего? ХФС не последовательно заполняет раздел?

     
     
  • 6.39, all_glory_to_the_hypnotoad (ok), 13:26, 06/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    нет. XFS сделана для многопоточной записи. Несколько потоков будут писаться в разные AG, но не факт что на разные носители. И со временем ФС "дефрагментируется", вероятность того, что используемые файлы в текущий момент окажутся на одном носителе не велика. От этого есть профит если юзать её на высоконагруженном сервере и с большим заполнением тома (порядка 50 % и выше)
     
     
  • 7.40, metallic (ok), 13:27, 06/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > нет. XFS сделана для многопоточной записи. Несколько потоков будут писаться в разные
    > AG, но не факт что на разные носители. И со временем
    > ФС "дефрагментируется", вероятность того, что используемые файлы в текущий момент окажутся
    > на одном носителе не велика. От этого есть профит если юзать
    > её на высоконагруженном сервере и с большим заполнением тома (порядка 50
    > % и выше)

    Т.е. при использовании страйпа я потеряю производительность после того, как том заполнится на >50% ?

     
     
  • 8.46, all_glory_to_the_hypnotoad (ok), 22:18, 06/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    нет, выше речь о другом - страйпить данные по объёму диска может и сама ФС, не... текст свёрнут, показать
     
  • 6.44, Аноним (-), 21:47, 06/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > За счет чего? ХФС не последовательно заполняет раздел?

    Allocation groups же.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру