форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

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

"Оценка эффективности работы 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... Новость: http://www.opennet.dev/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 (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 (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 (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 | Индекс форумов | Темы | Пред. тема | След. тема