The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Оценка эффективности работы fsck на гигантских разделах XFS ..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от opennews (??) on 04-Фев-12, 22:09 
Представлены (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...
Новость: https://www.opennet.ru/opennews/art.shtml?num=32994

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +1 +/
Сообщение от Аноним (??) on 04-Фев-12, 22:09 
> Ext4
> 72 Тб

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от StreamThreader (ok) on 04-Фев-12, 22:11 
А в чём проблема то?
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

5. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от Аноним (??) on 04-Фев-12, 22:41 
еще недавно было только 16
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

6. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от pumainthailand.com on 04-Фев-12, 22:57 
ПО моему это было ограничение софта для создания разделов, а не самой файловой системы.
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

9. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +3 +/
Сообщение от Аноним (??) on 05-Фев-12, 00:30 
> ПО моему это было ограничение софта для создания разделов, а не самой
> файловой системы.

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

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +4 +/
Сообщение от Stax (ok) on 04-Фев-12, 23:53 
В ноябре были выпущены e2fsprogs, в которых сделали создание систем >16 Тб - http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.42
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

7. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +2 +/
Сообщение от Anonus on 04-Фев-12, 23:07 
лучше бы время fsmark показали
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

14. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +5 +/
Сообщение от anonymous (??) on 05-Фев-12, 09:04 
А в обсуждении скорости работы xfs Благородный Дон напишет "лучше бы время fsck показали".
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

32. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от Anonus on 06-Фев-12, 01:37 
нет
Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

10. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +4 +/
Сообщение от pavlinux (ok) on 05-Фев-12, 04:24 
> XFS -- rw,noatime,attr2,nobarrier,inode64,noquota

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

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

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

13. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +1 +/
Сообщение от John (??) on 05-Фев-12, 08:51 
> Да и без барьеров это не файловая система, это файловая помойка.

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

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

17. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 05-Фев-12, 12:35 
такие же как и везде
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

20. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от Аноним (??) on 05-Фев-12, 14:58 
На чём-то сложнее зеркала барьеры не работают.
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

22. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от pavlinux (ok) on 05-Фев-12, 15:47 
> На чём-то сложнее зеркала барьеры не работают.

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

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

41. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от Andrew Kolchoogin on 06-Фев-12, 18:41 
Барьеры вообще не нужны. Должен быть RAID-контроллер с BBU. Если его нет -- значит, данные некритичные.
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

45. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 06-Фев-12, 22:04 
если данные действительно важные, то на контроллере выключают кеш на запись и используют барьеры.
Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

21. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от Аноним (??) on 05-Фев-12, 15:46 
> А правильные sunit и swidth вообще творят чудеса.

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

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

23. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  –1 +/
Сообщение от pavlinux (ok) on 05-Фев-12, 15:49 
>> А правильные sunit и swidth вообще творят чудеса.
> А разве они автоматом не определяются?

Неа. Unix way :)

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

25. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от ананим on 05-Фев-12, 16:40 
это ты зря.
xfs сейчас в автомате очень не плохо создаётся.
Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

42. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от Аноним (??) on 06-Фев-12, 21:44 
> xfs сейчас в автомате очень не плохо создаётся.

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

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

47. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от ананим on 08-Фев-12, 02:51 
>И откуда он должен узнать удобный для рэйда кусок? Рэйдов и их метаданных в природе существует целый легион.

и что?

Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

11. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от Аноним (??) on 05-Фев-12, 07:13 
Забыли указать сколько оно памяти жрет в процессе. У меня fsck.xfs на 20ТБ выжрало 44ГБ памяти.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от phaoost (ok) on 05-Фев-12, 08:03 
это где ж ей столко памяти найти
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

15. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +3 +/
Сообщение от Аноним (??) on 05-Фев-12, 09:48 
Где-нить рядышком на соседнем НЖМД?
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

18. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 05-Фев-12, 12:36 
нашёл 20 тб хранилище, найдёшь и столько памяти. Для сервера размеры вполне типичные
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

19. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  –1 +/
Сообщение от Аноним (??) on 05-Фев-12, 12:57 
Для сервера чего? Мордокниги? :D:D:D
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

24. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от Stax (ok) on 05-Фев-12, 16:23 
Ога, да.
Вот у меня домашнее хранилище:
$ 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 гига подавай.. не жирно будет?

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

26. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +2 +/
Сообщение от Аноним (??) on 05-Фев-12, 16:48 
> (это 10 трехтерабайтников в raidz2, расшаренных по nfs).

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

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

27. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +1 +/
Сообщение от ананим on 05-Фев-12, 16:54 
>На этом фоне очень странно выглядят придирки

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

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

31. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от Stax (ok) on 06-Фев-12, 00:38 
Эээ расскажите, как оценивали :)
Сейчас 16 гигабайт памяти, они почти все чисто под кэш - раньше было 8, работало тоже хорошо. Сама по себе фс требует копейки, ну сотни мегабайт, возможно; все остальное - это кэш ARC, конечно, чем больше, чем лучше, но это зависит от задачи. Если много случайного чтения, сосредоточенного в определенных кусках диска (скажем, сторейдж для виртуалок), то есть смысл в большом объеме памяти, SSD под кэш и прочее. Но если операции в основном последовательные, как на домашнем NAS или на бэкап-сервере, то паямти много не нужно. На солярке систему под эти нужды можно и на 4 Гб развернуть, работать будет точно так же по скорости - хоть 20 Тб фс, хоть 40. Например, сейчас из 16 гигов на этой системе 11 гигов свободно - ну нет никакого смысла кэшировать последовательные чтения.
А сам по себе raidz памяти не потребляет. Ему не зачем. Проверка, которая scrub, тоже памяти не требует.

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

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

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

34. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от Аноним (??) on 06-Фев-12, 03:35 
> Эээ расскажите, как оценивали :)

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

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

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

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

33. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 06-Фев-12, 02:11 
> Между прочим, полно и других подобных задач, например бэкап-сервер в небольшой огранизации. Место нужно много терабайт, а память не нужна практически совсем - оно же под последовательную запись, изредка бывает что-то нужно последовательно считать, там независимо от объема хранилища 4-8 Гб будет за глаза, и то чисто формально (хватило бы и 2 Гб), потому что меньше как-то нет смысла ставить. А xfs'у 44 гига подавай.. не жирно будет?

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

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

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

16. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от Аноним (??) on 05-Фев-12, 09:51 
32 Гига ОЗУ не хватило. Пришлось экстренно создавать файл подкачки.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

43. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от Аноним (??) on 06-Фев-12, 21:46 
> 32 Гига ОЗУ не хватило.

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

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

30. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от metallic (ok) on 05-Фев-12, 21:31 
У меня аналогичный конфиг, 90ТБ на XFS (192 диска по 600ГБ, 12 RAID6 по 16 дисков, объединены LVM в страйп)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

35. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от Аноним (??) on 06-Фев-12, 03:37 
> У меня аналогичный конфиг, 90ТБ на XFS (192 диска по 600ГБ, 12
> RAID6 по 16 дисков, объединены LVM в страйп)

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

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

36. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от metallic email(ok) on 06-Фев-12, 10:28 
Именно в страйп, в линейной группе не будет прироста производительности.
Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

37. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 06-Фев-12, 11:01 
на xfs будет. Правда, смотря как её измерять.
Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

38. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от metallic email(ok) on 06-Фев-12, 11:02 
> на xfs будет. Правда, смотря как её измерять.

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

Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

39. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 06-Фев-12, 13:26 
нет. XFS сделана для многопоточной записи. Несколько потоков будут писаться в разные AG, но не факт что на разные носители. И со временем ФС "дефрагментируется", вероятность того, что используемые файлы в текущий момент окажутся на одном носителе не велика. От этого есть профит если юзать её на высоконагруженном сервере и с большим заполнением тома (порядка 50 % и выше)
Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

40. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от metallic email(ok) on 06-Фев-12, 13:27 
> нет. XFS сделана для многопоточной записи. Несколько потоков будут писаться в разные
> AG, но не факт что на разные носители. И со временем
> ФС "дефрагментируется", вероятность того, что используемые файлы в текущий момент окажутся
> на одном носителе не велика. От этого есть профит если юзать
> её на высоконагруженном сервере и с большим заполнением тома (порядка 50
> % и выше)

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

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

46. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 06-Фев-12, 22:18 
нет, выше речь о другом - "страйпить" данные по объёму диска может и сама ФС, не обязательно делать для этого страйп. Но XFS "страйпить" будет если одновременно писать на диск из нескольких приложений в разные файлы.

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

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

Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

44. "Оценка эффективности работы fsck на гигантских разделах XFS ..."  +/
Сообщение от Аноним (??) on 06-Фев-12, 21:47 
> За счет чего? ХФС не последовательно заполняет раздел?

Allocation groups же.

Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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