The OpenNET Project / Index page

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

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

Представлены результаты оценки эффективности работы утилиты 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
Тип: английский / Практикум
Ключевые слова: xfs, ext4, fsck
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | 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 +/
    Позвольте узнать, сколько это ваше счастье-то жрет По самым скромным оценкам, д... весь текст скрыт [показать]
     
     
  • 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 [^] [ответить]     [к модератору]  
  • +/
    По опыту попыток применения на продакшенах Разумеется, при тестировании мы отню... весь текст скрыт [показать]
     
  • 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 [^] [ответить]    [к модератору]  
  • +/
    нет, выше речь о другом - "страйпить" данные по объёму диска может и сама ФС, не обязательно делать для этого страйп. Но XFS "страйпить" будет если одновременно писать на диск из нескольких приложений в разные файлы.

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

    Потеряет страйп производительность или нет скорее зависит от того, как ФС умеет предугадывать выделение дискового пр-ва при записи (см. delayed allocation  и allocsize у xfs)

     
  • 6.44, Аноним (-), 21:47, 06/02/2012 [^] [ответить]    [к модератору]  
  • +/
    > За счет чего? ХФС не последовательно заполняет раздел?

    Allocation groups же.

     

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


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