LINUX.ORG.RU

Деградация zfs, btrfs при заполнении диска

 ,


5

6

Не так давно я перевёл свою домашнюю файлопомойку (1x1TB, 2x500GB) на zfs. Дисков мало, все они разные, поэтому никакого рейда — просто критические данные лежат на подтоме, для которого включено дублирование данных.

Сначала всё было хорошо. Потом ввод-вывод стал дико тормозить. А потом я наткнулся на статью, в которой красочно рассказано, как расп-дорашивает zfs от случайных перезаписей, если забить её данными хотя бы наполовину. А у меня из 1.8T занято 1.5T, и, видимо, так дальше жить нельзя.

Отсюда три вопроса:

  1. что делать (помимо того, что «вдоль» и «докупать больше дисков»)?
  2. как будут обстоять дела в подобных ситуациях у btrfs?
  3. какие ещё есть ФС из «комбайнов» со снапшотами, подтомами, компрессией и так далее?

Update #1. Нагрузка на ФС — торренты и sqlite-овая БД размером в один гигабайт. Тормоза наблюдаются с последней.

Update #2. После того, как я сделал synchronous = 0; для sqlite-овой БД, всё стало сильно лучше. Вопрос «какого хрена?» всё ещё в силе, т. к. intent log имеется.

★★★★★

Последнее исправление: intelfx (всего исправлений: 4)
Ответ на: комментарий от bigbit

Ну.. Ты как бы совершенно точно описал работу рейда в режиме degraded , разве что шпинделя не синхронизируются, хотя.. и это может иметь место. Этот товарищ не могет понять что с нормально живого рейда чтение с дисков идёт асинхронно, а с больного - синхронно, отсюда большая просадка random read per second. А вот sequence read не даёт такой просадки в bytes per second.

anonymous
()

Мне надоело читать спор двух человек об очевидном implementation defined behavior, поэтому я вброшу ещё: у меня ZoL стабильно каждые четыре-пять дней отправлял систему в даун (почему — не знаю, оно тут же переподнималось по ватчдогу, а в логах пусто, что свидетельствует о том, что подсистема writeback ядра ложилась на лопатки). А btrfs уже неделю как работает.

Для ынтырпрайза не показатель, но тем не менее.

Насчёт load average сказать ничего не могу, потому что я одновременно сменил базу данных с SQLite на постгрес (и обычный страйп на RAID5, докинув дисков), но вот transmission теперь жрёт CPU на порядок меньше (было 20-30%, стало 3-5%).

intelfx ★★★★★
() автор топика
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от bigbit

Так что-ли по-твоему работает RAID ?

Я в курсе, что mdadm позволяет сделать RAID из разделов на одном HDD. Наверное, ты считаешь, что это хороший вариант, да ?

AS ★★★★★
()
Ответ на: комментарий от anonymous

Ты их так ещё больше запутаешь:)

А уж как ты запутаешься, когда тебе намекнут про кэш самого контроллера... Да ещё и с батарейкой (хотя это к вопросу записи уже), да на пару гигабайт... Да ? :-)

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от intelfx

очевидном implementation defined behavior

ты про параллельное чтение в raid5?

вброшу ещё: у меня ZoL стабильно каждые четыре-пять дней отправлял систему в даун

и? у меня ZFS на FreeBSD/OmniOS, работает как часы, а ZoL на proxmox валил систему в процессе старта второй виртуалки.

сменил базу данных с SQLite на постгрес (и обычный страйп на RAID5)

БД на raid5? Гыыы

anonymous
()
Ответ на: комментарий от AS

и в чем твой намек? кэш с батарейкой делает запись быстрее? кэш контроллера меняет логику работы рейда?

anonymous
()
Ответ на: комментарий от intelfx

у меня ZoL стабильно каждые четыре-пять дней отправлял систему в даун

master@vm-host27:~$  uptime
10:58:24 up 255 days, 13:20,  1 user,  load average: 0.88, 0.63, 0.67

Ни одного дауна не встречал, все дауны ушли жить в твой nas :)

anonymous
()
Ответ на: комментарий от anonymous

ты про параллельное чтение в raid5?

Да.

и? у меня ZFS на FreeBSD/OmniOS, работает как часы

Рад за тебя, но мне нужен Linux.

БД на raid5? Гыыы

Что не так?

intelfx ★★★★★
() автор топика
Ответ на: комментарий от intelfx

ты про параллельное чтение в raid5?

Да.

Оно не implementation, а by design такое.

БД на raid5? Гыыы

Что не так?

Да как бы не делают БД на 5 рейде. И как у тебя с random write ?

anonymous
()
Ответ на: комментарий от anonymous

Да как бы не делают БД на 5 рейде.

Почему? Где почитать?

И как у тебя с random write ?

Не жалуюсь. Чем померить?

intelfx ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Поиском по sql.ru ничего не нашёл. В списках рассылки постгреса тоже ничего путного, все апеллируют к очевидности.

И нет, у меня обычные десктопные жёсткие диски.

intelfx ★★★★★
() автор топика
Ответ на: комментарий от anonymous

кэш контроллера меняет логику работы рейда ?

А что, нет ?

кэш с батарейкой делает запись быстрее ?

Тебе подсказать, как ?

AS ★★★★★
()
Ответ на: комментарий от intelfx

Представь себе, нет.

Он, очевидно, намекает на write penalty. У RAID5, в теории (у soft raid особенно), это серьёзная проблема. Но он просто имел дело с говнораидами. О чём последние несколько страниц. ;-)

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от AS

У меня как раз софтрейд (точнее, рейд средствами btrfs, т. е. теоретически с переменным stride). Почему я не прав?

intelfx ★★★★★
() автор топика
Ответ на: комментарий от intelfx

(точнее, рейд средствами btrfs, т. е. теоретически с переменным stride). Почему я не прав?

Вот тут я не готов что-то говорить. RAID средствами ФС, для меня, сильно новое колдунство.

AS ★★★★★
()
Ответ на: комментарий от AS

Каким образом кэш меняет логику в/в блоков с дисков?

Ага, подскажи каким образом поток команд write(random(0..100500)) на raid5 будет писаться быстрее ?

anonymous
()
Ответ на: комментарий от AS

write penalty. У RAID5, в теории (у soft raid особенно), это серьёзная проблема.

Только в теории? А на практике с этим как? Ты, судя по всему, со многими массивами работал.

bigbit ★★★★★
()
Ответ на: комментарий от AS

Я намекаю на то что с random write у raid5 все печально.

Последние несколько страниц о том что ты нихрена не понимаешь в теме.

anonymous
()
Ответ на: комментарий от bigbit

У raid5(6) random write penalty by design, но это нивелируется чуть более чем полностью если raid on ssd.

anonymous
()
Ответ на: комментарий от anonymous

Ага, подскажи каким образом поток команд
write(random(0..100500)) на raid5 будет писаться быстрее ?

Подскажи мне, зачем вообще что-то куда-то писать, если, пока данные висят в кэше, прилетает следующий блок на то же место ? На то и батарейка, и здоровый кэш, чтобы с записью не спешить.

AS ★★★★★
()
Ответ на: комментарий от AS

как и о cache overload

впрочем, чему я удивляюсь...

anonymous
()
Ответ на: комментарий от anonymous

о sync write ты не слышал?

Нет, не слышал: железный RAID тебе всё подтвердит, но это не значит, что он реально положит на HDD, когда у него включен режим кэширования записи. хоть обsyncайся. А совсем правильный RAID его без батарейки не включает.

как и о cache overload

А если у тебя cache overload случается, это значит, что у тебя в консерватории что-то не то: недостаточно производительную систему выбрал под задачу.

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 2)
Ответ на: комментарий от AS

Нет, не слышал: железный RAID тебе всё подтвердит, но это не значит, что он реально положит на HDD

угу, точно не слышал.

А если у тебя cache overload случается, это значит, что у тебя в консерватории что-то не то: недостаточно производительную систему выбрал под задачу.

Он случается даже на твоем локалхосте, причем регулярно.

вопчем ты 0.(0) в теме

anonymous
()
Ответ на: комментарий от AS

Ты всё ещё пытаешься отмыться и показать, что тоже в теме? не, уже поздно.

RAID, для меня, сильно новое колдунство.

поправил, не благодари.

EvgGad_303 ★★★★★
()
Ответ на: комментарий от EvgGad_303

Ты всё ещё пытаешься отмыться и показать, что тоже в теме? не, уже поздно.

Ты можешь думать всё, что хочешь. На уровне mdadm твои знания, вероятно, сгодядся.

AS ★★★★★
()
Ответ на: комментарий от anonymous

Он случается даже на твоем локалхосте, причем регулярно.

На моём локалхосте нет аппаратного энергонезависимого кэша.

AS ★★★★★
()
Ответ на: комментарий от EvgGad_303

Страйп - это группа nD+mP, чанк - то, что попадает на один диск

в терминологии RAID группа A(A1,A2,A3...AN) это Full Stripe, Stripe это АN. чанк это из MDADM, странная терминология.

anonymous
()
Ответ на: комментарий от anonymous

Stripe это АN. чанк это из MDADM, странная терминология.

Не только, некоторые стораж вендоры тоже так обзываются.

EvgGad_303 ★★★★★
()
Ответ на: комментарий от EvgGad_303

я про классическую терминологию.

а так то да, некоторые вендоры под страйпом имеют ввиду фуллстрайп (как recordsize в raidzN). вопщем раньше проще было с терминами :)

anonymous
()
Ответ на: комментарий от AS

EvgGad_303 вот утверждает, что этот алгоритм у кого-то описан.

Искал я тут давеча кое-что в сурсах zfs и как специально для тебя в vdev_raidz.c это описано, если ты до сих пор ещё в потёмках.

EvgGad_303 ★★★★★
()
Ответ на: комментарий от EvgGad_303

Искал я тут давеча кое-что в сурсах zfs и как специально для тебя в vdev_raidz.c

Ну так-то я уже упоминал, что mdadm позволяет создать RAID из разделов, вовсе, одного HDD. Это же не делает, автоматом, такое поведение нормальным ? Плюс мы не обсуждали варианты всякой экзотики с объединением ФС+RAID (ага, то что в теме, как раз), правда ведь ? Так что чуть-чуть мимо пока.

AS ★★★★★
()
Ответ на: комментарий от AS

Не надо ставить пробел перед вопросительным знаком, это снижает видимость достоверности твоей писанины в 9000 раз. Всем известно, люди не осилившие правила пунктуации, ни на что не годны.

anonymous
()
Ответ на: комментарий от AS

блеать, ты совсем дурачок, иди уже открой гугл и найди доказательства обратного, раз ты такой, кхммм...

EvgGad_303 ★★★★★
()
Ответ на: комментарий от AS

Вот хороший букварь: http://www.amazon.com/gp/product/1118094832/

В электронном виде доступен здесь.

Надеюсь, это все прояснит:

стр. 57:
RAID 3 Parallel access array with dedicated parity disk
RAID 4 Striped array with independent disks and a dedicated parity disk
RAID 5 Striped array with independent disks and distributed parity

стр. 59
RAID 3
RAID 3 always reads and writes complete stripes of data across all disks, as the drives operate in parallel. There are no partial writes that update one out of many strips in a stripe.

стр. 61
RAID 4
Unlike RAID 3, data disks in RAID 4 can be accessed independently so that specific data elements can be read or written on single disk without read or write of an entire stripe.

стр. 62
RAID 5
RAID 5 is a very versatile RAID implementation. It is similar to RAID 4 because it uses striping and the drives (strips) are independently accessible.

bigbit ★★★★★
()
Ответ на: комментарий от bigbit

В электронном виде доступен здесь.
Надеюсь, это все прояснит:

Букварь интересный. Спасибо.

Кое-что из реальной жизни (пямо сейчас сделанный тест). Имеем контроллер:
Intel (R) RAID Controller RS25DB080

Это вот сборка ядра на RAID5 из 5HDD (два раза подряд одно и то же):

6973.06user 1364.19system 23:10.06elapsed 599%CPU (0avgtext+0avgdata 255940maxresident)k
31096inputs+5591360outputs (145major+249444882minor)pagefaults 0swaps

6976.36user 1359.22system 23:12.19elapsed 598%CPU (0avgtext+0avgdata 255940maxresident)k
2024inputs+5591408outputs (28major+249438218minor)pagefaults 0swaps

Вытаскиваем 1 HDD и делаем то же самое, опять дважды:

6977.77user 1359.57system 23:15.53elapsed 597%CPU (0avgtext+0avgdata 255944maxresident)k
627488inputs+5591400outputs (174major+249425559minor)pagefaults 0swaps

6974.95user 1360.98system 23:11.99elapsed 598%CPU (0avgtext+0avgdata 255940maxresident)k
627984inputs+5591368outputs (139major+249400299minor)pagefaults 0swaps

Железяка 8-ядерная, ядро, по-умолчанию, собирается на всех ядрах, то есть, имеем хорошее распараллеливание. В момент пересборки не знималась больше ни чем. График загрузки по LA примерно одинаковый для всех 4-х случаев. В общем, я не вижу просадки в производительности у деградированного RAID5 на RS25DB080 (1Гб кэш, с батарейкой). Да, можно посчитать, что я не подходил близко к пределу производительности с этим тестом.

EvgGad_303 Что-нибудь ещё потестируем, пока железка стоит без работы ?

AS ★★★★★
()
Ответ на: комментарий от AS

Собственно, сборка в процессе ребилда массива тоже в пределах погрешности:

6976.63user 1360.95system 23:18.06elapsed 596%CPU (0avgtext+0avgdata 255940maxresident)k
176512inputs+5591368outputs (334major+249366526minor)pagefaults 0swaps

AS ★★★★★
()
Ответ на: комментарий от anonymous

Тест ниачом.

Предлагай.

Ты узнал что при компиляции влияние io ничтожно, поздравляю, садись пять!

Да, меня мало волнуют синтетические тесты.

AS ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.