| |
| |
| |
| |
| 5.9, Аноним (-), 00:30, 05/02/2012 [^] [^^] [^^^] [ответить]
| +3 +/– |
> ПО моему это было ограничение софта для создания разделов, а не самой
> файловой системы.
Именно так, mke2fs не умел создавать тома больше, но сама ФС вполне умела работать и с более крупными томами.
| | |
|
|
|
|
| |
| 2.14, anonymous (??), 09:04, 05/02/2012 [^] [^^] [^^^] [ответить]
| +5 +/– |
А в обсуждении скорости работы xfs Благородный Дон напишет "лучше бы время fsck показали".
| | |
|
| 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?
| | |
| |
| |
| |
| 5.22, pavlinux (ok), 15:47, 05/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 :)
| | |
| |
| |
| 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ГБ памяти.
| | |
| |
| |
| |
| 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.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 [^] [^^] [^^^] [ответить]
| +/– |
Именно в страйп, в линейной группе не будет прироста производительности.
| | |
| |
| |
| 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% ?
| | |
|
| 6.44, Аноним (-), 21:47, 06/02/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> За счет чего? ХФС не последовательно заполняет раздел?
Allocation groups же.
| | |
|
|
|
|
|
|
