Представлены (http://www.enterprisestorageforum.com/storage-hardware/linux...) результаты оценки эффективности работы утилиты fsck при проверке файловых систем XFS и Ext4. Особенностью проведённых тестов является размер проверяемых данных - для каждой из ФС эксперименты проводились на разделе, размером 72 Тб: DDN SFA10K-X из 590 дисков по 450 Гб, на базе которых создано 23 RAID-6 по 10 дисков в каждом, которые объединены в единый раздел при помощи mdadm. Для заполнения раздела на 50% использовалась утилита fs_mark (http://sourceforge.net/projects/fsmark/), позволяющая сгенерировать структуру каталогов с наполненными случайными данными файлами (в разных тестах создано 100-400 млн файлов).
Результаты:
<center>
<table style="border: 1px solid rgb(176, 177, 144); border-collapse: collapse; background: none repeat scroll 0% 0% rgb(221, 225, 194);" cellpadding="2" cellspacing="0" width="50%" border="1"><tbody>
<tr>
<td>Размер ФС в ...URL: http://www.enterprisestorageforum.com/storage-hardware/linux...
Новость: http://www.opennet.me/opennews/art.shtml?num=32994
> Ext4
> 72 Тбэто когда появилось?
А в чём проблема то?
еще недавно было только 16
ПО моему это было ограничение софта для создания разделов, а не самой файловой системы.
> ПО моему это было ограничение софта для создания разделов, а не самой
> файловой системы.Именно так, mke2fs не умел создавать тома больше, но сама ФС вполне умела работать и с более крупными томами.
В ноябре были выпущены e2fsprogs, в которых сделали создание систем >16 Тб - http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.42
лучше бы время fsmark показали
А в обсуждении скорости работы xfs Благородный Дон напишет "лучше бы время fsck показали".
нет
> XFS -- rw,noatime,attr2,nobarrier,inode64,noquotaПля, сто тыщь мильонов раз говорил, для attr2 надо специально готовить FS,
просто /sbin/mkfs.xfs -f /dev/md1 - толку НОЛЬ.
Могли бы ещё больше разогнать, добавив хотябы mkfs.xfs –i attr=2А правильные sunit и swidth вообще творят чудеса.
---
Да и без барьеров это не файловая система, это файловая помойка.
> Да и без барьеров это не файловая система, это файловая помойка.Какие барьеры на software RAID?
такие же как и везде
На чём-то сложнее зеркала барьеры не работают.
> На чём-то сложнее зеркала барьеры не работают.Работают, тока они нафиг не нужны. Видимо данные не совсем крытичные
Барьеры вообще не нужны. Должен быть RAID-контроллер с BBU. Если его нет -- значит, данные некритичные.
если данные действительно важные, то на контроллере выключают кеш на запись и используют барьеры.
> А правильные sunit и swidth вообще творят чудеса.А разве они автоматом не определяются?
>> А правильные sunit и swidth вообще творят чудеса.
> А разве они автоматом не определяются?Неа. Unix way :)
это ты зря.
xfs сейчас в автомате очень не плохо создаётся.
> xfs сейчас в автомате очень не плохо создаётся.И откуда он должен узнать удобный для рэйда кусок? Рэйдов и их метаданных в природе существует целый легион.
>И откуда он должен узнать удобный для рэйда кусок? Рэйдов и их метаданных в природе существует целый легион.и что?
Забыли указать сколько оно памяти жрет в процессе. У меня fsck.xfs на 20ТБ выжрало 44ГБ памяти.
это где ж ей столко памяти найти
Где-нить рядышком на соседнем НЖМД?
нашёл 20 тб хранилище, найдёшь и столько памяти. Для сервера размеры вполне типичные
Для сервера чего? Мордокниги? :D:D:D
Ога, да.
Вот у меня домашнее хранилище:
$ 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 гига подавай.. не жирно будет?
> (это 10 трехтерабайтников в raidz2, расшаренных по nfs).Позвольте узнать, сколько это ваше счастье-то жрет? По самым скромным оценкам, для нормальной работы raidz такого объема нужно гига 64.
На этом фоне очень странно выглядят придирки к 44 гигам для оффлайновой проверки (а не непрерывной рантаймовой работы).
>На этом фоне очень странно выглядят придиркиэто потому что фс некоторые выбирают для понтов, а не для работы.
поэтому как бы глупо отвечать, что xfs со своей многопоточностью ну очень хороша для высоконагруженных серверов и эту её особенность ни чуть не портит эта мелкая неприятность.
Эээ расскажите, как оценивали :)
Сейчас 16 гигабайт памяти, они почти все чисто под кэш - раньше было 8, работало тоже хорошо. Сама по себе фс требует копейки, ну сотни мегабайт, возможно; все остальное - это кэш ARC, конечно, чем больше, чем лучше, но это зависит от задачи. Если много случайного чтения, сосредоточенного в определенных кусках диска (скажем, сторейдж для виртуалок), то есть смысл в большом объеме памяти, SSD под кэш и прочее. Но если операции в основном последовательные, как на домашнем NAS или на бэкап-сервере, то паямти много не нужно. На солярке систему под эти нужды можно и на 4 Гб развернуть, работать будет точно так же по скорости - хоть 20 Тб фс, хоть 40. Например, сейчас из 16 гигов на этой системе 11 гигов свободно - ну нет никакого смысла кэшировать последовательные чтения.
А сам по себе raidz памяти не потребляет. Ему не зачем. Проверка, которая scrub, тоже памяти не требует.Конечно, есть и другие факторы, например, если добавить SSD под кэш, то потребуется пара-тройка гигов в оперативке для хранения индексов по той части кэша, которая на SSD. Но это все нюансы, да и цифры на порядок отличаются от тех, кто нужны zfs.
А "придирка" по поводу проверки против рантаймовой работы - это, знаете, совсем не придирка. Вы пойдете добавлять в сервер, где сейчас 8 гигов памяти 40 дополнительных в момент запуска проверки, что ли?
> Эээ расскажите, как оценивали :)По опыту попыток применения на продакшенах.
Разумеется, при тестировании мы отнюдь не стремились воспроизвести тепличные условия с последовательным чтением, как вы описываете. Все-таки не путаем винчестеры со стримерами.> А "придирка" по поводу проверки против рантаймовой работы - это, знаете, совсем не придирка. Вы пойдете добавлять в сервер, где сейчас 8 гигов памяти 40 дополнительных в момент запуска проверки, что ли?
Нет, просто оффлайн, как правило, не стеснен во времени (на то и нужны дублирующие сервера), а значит, прекрасно поработает и со свопом.
> Между прочим, полно и других подобных задач, например бэкап-сервер в небольшой огранизации. Место нужно много терабайт, а память не нужна практически совсем - оно же под последовательную запись, изредка бывает что-то нужно последовательно считать, там независимо от объема хранилища 4-8 Гб будет за глаза, и то чисто формально (хватило бы и 2 Гб), потому что меньше как-то нет смысла ставить. А xfs'у 44 гига подавай.. не жирно будет?Конкретно в этом юз кейсе вы себе придумываете проблему из воздуха. Во-первых, для задач бэкапа и последовательных чтений/записи нужно использовать ленточки, да ещё на таких объёмах. Ну если нет $ на ленточки и есть на массив под бэкапы, то нахрена а) юзать именно xfs и б) делать одну монолитную ФС на десятки Тб? Это же просто идиотизм. Причём, не только для xfs.
Все вменяемые бэкапилки спокойно могут работать с кучей ФС, шинковать по ним сколько угодно файлов, а некоторые из них даже просто с сырыми разделами, вообще без ФС.
32 Гига ОЗУ не хватило. Пришлось экстренно создавать файл подкачки.
> 32 Гига ОЗУ не хватило.А сколько диск был? :)
У меня аналогичный конфиг, 90ТБ на XFS (192 диска по 600ГБ, 12 RAID6 по 16 дисков, объединены LVM в страйп)
> У меня аналогичный конфиг, 90ТБ на XFS (192 диска по 600ГБ, 12
> RAID6 по 16 дисков, объединены LVM в страйп)В страйп или просто в линейную группу?
Именно в страйп, в линейной группе не будет прироста производительности.
на xfs будет. Правда, смотря как её измерять.
> на xfs будет. Правда, смотря как её измерять.За счет чего? ХФС не последовательно заполняет раздел?
нет. XFS сделана для многопоточной записи. Несколько потоков будут писаться в разные AG, но не факт что на разные носители. И со временем ФС "дефрагментируется", вероятность того, что используемые файлы в текущий момент окажутся на одном носителе не велика. От этого есть профит если юзать её на высоконагруженном сервере и с большим заполнением тома (порядка 50 % и выше)
> нет. XFS сделана для многопоточной записи. Несколько потоков будут писаться в разные
> AG, но не факт что на разные носители. И со временем
> ФС "дефрагментируется", вероятность того, что используемые файлы в текущий момент окажутся
> на одном носителе не велика. От этого есть профит если юзать
> её на высоконагруженном сервере и с большим заполнением тома (порядка 50
> % и выше)Т.е. при использовании страйпа я потеряю производительность после того, как том заполнится на >50% ?
нет, выше речь о другом - "страйпить" данные по объёму диска может и сама ФС, не обязательно делать для этого страйп. Но XFS "страйпить" будет если одновременно писать на диск из нескольких приложений в разные файлы.50 процентов условная цифра, просто означает некую меру высокой утилизации дискового пр-ва. Когда диск фрагментирован, то хочешь этого или нет, ФС приходится разбрасывать данные по всему диску, т.е. попадать они будут почти наверное на разные физические носители и без страйпа.
Потеряет страйп производительность или нет скорее зависит от того, как ФС умеет предугадывать выделение дискового пр-ва при записи (см. delayed allocation и allocsize у xfs)
> За счет чего? ХФС не последовательно заполняет раздел?Allocation groups же.