root on ZFS

lexa - 12/Дек/2009 19:13
Для тонких ценителей. 
zroot on / (zfs, local)
zroot/home on /home (zfs, local)
zroot/tmp on /tmp (zfs, local, nosuid)
zroot/usr on /usr (zfs, local)
..... и еще с десяток томов под разные нужды....
3 диска, RAIDZ1, 4 терабайта места, "домашний роутер".

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

В частности, расширять root pool нельзя, поэтому идея-фикс по переносу данных без многократного переписывания данных не проканала. А была она такая:

  • Было два двухтерабайтника в зеркале, место кончилось, купил третий.
  • Разбиваем зеркало, из двух дисков (один старый, один новый) делаем RAIDZ1, переписываем туда данные.
  • Добавляем второй старый диск в тот же RAID.
Увы, пришлось вылить на внешние диски, собрать массив, налить обратно....

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

Comments

_slw (not verified) - 12/Дек/2009 16:32

а вот в связи с идиотизмом и жадностью менеджеров от интернету через нас клиент зарегистрил домен .рф.

посему у меня вопросы:

1. черный квадрат на .рф расширяться будет?
2. что броузеры в Host: на такое пишут?
3. что мылеры в RCPT TO:?

lexa - 12/Дек/2009 16:47

По второму-третьему пункту там вроде бы IDN, т.е. все упрятано в латиницу. Правда вот такие люди захотят еще юзер-собака-домен.рф а что мейлеры подумают про левую часть есть большой вопрос.

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

lair (not verified) - 12/Дек/2009 20:33

На восьмерке?

lexa - 12/Дек/2009 20:38

Ну да, на ней. ZFS version 13.

mdounin (not verified) - 13/Дек/2009 00:37

Безумству храбрых... Впрочем, домашний роутер - не бином ньютона, уйдёт в дедлок - перегрузить не сложно. Главное бэкапиться не забывай. :)

lexa - 13/Дек/2009 06:37

Вот именно, перегрузить несложно.
Вся опупея была затеяна по той причине, что жесткая перезагрузка с gmirror - это ребилд. И одновременно fsck.

Что же до бэкапа, то это наоборот destination для бэкапов, для того и терабайты.

Ну и естественно, вся конструкция - чтобы посмотреть. Предыдущий подход к ZFS был неудачный, постоянные ребуты. Но было i386 и два гига, сейчас amd64 и 8.

poige (not verified) - 13/Дек/2009 11:49

> жесткая перезагрузка с gmirror - это ребилд.
> И одновременно fsck.

Хех. Как же, как же. Вот именно потому в мою бытность главным инженером одного небольшого телекома, в окрестности 2002 г. ( 1), FreeBSD была позорно изгнана с proxy-сервера и вместо неё установлен Linux (на Linux Software RAID (LSR) + Reiserfs). В то время vinum не умел background check/repair (в отличие от LSR), а только, так сказать foreground . Была-ли там UFS2 в то время с её background fsck, не уверен (скорее не было), но даже если бы и была, то сладкая парочка LSR + Reiserfs заруливала их по всем основным пунктам.

А что касается переносу данных без многократного переписывания , то на своём домашнем desktop-server'е проделывал такое ни раз, ибо LSR умеет on-line re-shape (добавить ещё один диск в RAID-5/6-вязанку не проблема, ровно как и из RAID-5 получить -6). В случае с RAID-1 всё делается именно так просто, как описано в твоей идеее , делал такое не так давно ремотно Причём, с LSR (если одновременно засунуть 3-и диска) всё можно сделать максимально надёжно, когда массив ни разу не будет degraded.

lexa - 13/Дек/2009 12:12

Re: > жесткая перезагрузка с gmirror - это ребилд.
FreeBSD мы любим не за это :)
А за это - да, не любим. Кроме ZFS (про которую нужно следствие эдак на полгода), есть еще gjournal, да и зеркалирование/RAID на большинстве серверов у нас - аппаратное.

geom raid5 у меня дома был, нормально в принципе, но потом я 3x750 горячих поменял на 2x2Tb (холодных, Caviar Green).

poige (not verified) - 13/Дек/2009 13:05

> Кроме ZFS (про которую нужно следствие эдак на полгода)
Меня, помнится, весьма впечатляла разница между скоростью выполнения squid -z на Reiserfs и UFS. Это к вопросу о том, что без ZFS фрю можно снова за это не любить

Кстати, а вот за что любить? :-) netflow? Что ещё на балансе? :-)

lexa - 13/Дек/2009 13:31

Re: > Кроме ZFS (про которую нужно следствие эдак на полгод
если нужно быстро создавать каталоги, можно -o async перемонтировать.

Что касается любви, то очень просто все со стороны разработчика. Когда мы делали спамтест (а это годы 2002-2005), линукс создавал на порядки больше гемороя, слишком много сортов дерьма. При том, что в россии продаж freebsd-шных было больше.
А так - включаешь и работает, что еще надо?

poige (not verified) - 13/Дек/2009 13:35

> можно -o async перемонтировать.
Ну как нам подсказывает : Если включены softupdates (а, скорее всего, они включены), то без размонтирования async не включить. . А с Reiserfs/EXT3 даже журналирование отключать не нужно, чтобы основательно дёрнуть UFS'ку по performance.

lexa - 13/Дек/2009 13:46

Re: > можно -o async перемонтировать.
По перформансу чего? Создания миллиона каталогов? Ну наверное да. Но какое отношение эта операция имеет к реальной жизни?

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

poige (not verified) - 13/Дек/2009 13:48

> Но какое отношение эта операция имеет к реальной жизн
Да такое же, когда у нас вдруг ну очень много файлов и каталогов. Для FreeBSD читай /usr/ports .

lexa - 13/Дек/2009 13:54

Re: > Но какое отношение эта операция имеет к реальной жи
portsnap работает какое-то совершенно разумное время, даже при extract. Всякие cd /usr/ports/*/p5-*-Netmask (что я практикую т.к. не помню в каком месте что лежит) - тоже работают.

Т.е. я бы не сказал, что это так уж мешает жить. Да и не так много там:
lexa@home-gw:/usr/ports# find . |wc -l
138155

lexa - 13/Дек/2009 14:04

Re: > Но какое отношение эта операция имеет к реальной жи
А не по портам, а по жизни: на боевых машинах "вдруг" не становится, передняя голова, проектирование.

На девелоперских бывает всякое конечно, вот сейчас посчитал файлы в $HOME, оказалось 150 тысяч. Ну типа да. Не знал.

poige (not verified) - 13/Дек/2009 13:13

> 3x750 горячих поменял на 2x2Tb (холодных, Caviar Green).
Это целых 2 TB ни тэбе, ни мине ? :-)

lexa - 13/Дек/2009 13:32

Re: > 3x750 горячих поменял на 2x2Tb (холодных, Caviar Green).
Зато я спокойно сплю. У меня там есть ненулевое количество теплых (свежеполученных) данных, которые восстанавливать дорого, дороже чем 250 баксов за двухтерабайтник.

poige (not verified) - 13/Дек/2009 13:51

> У меня там есть ненулевое количество теплых
Под ~ 2 TB? :-)

Нет, я понимаю, что за ваши деньги любые прихоти, но денег же вроде как много не бывает? :-) На LSR это можно было бы сделать как много места RAID-5 + не так много, но очень надёжно RAID-1 на 2-х, а то и 3-х разделах. :-)

lexa - 13/Дек/2009 14:01

Re: > У меня там есть ненулевое количество теплых
Там несколько сотен гигабайт - потому и дорого восстанавливать, просто долго, взять и все пересчитать.

Но оно постепенно копится, отчего общий пул всего на ZFS становится особенно ценен.

poige (not verified) - 13/Дек/2009 14:16

> взять и все пересчитать.
Ты про RAID parity re-calc, или? Если да, то у того же LSR есть write-intent bitmap весьма Кроме того, как уже сказал, ничто же не мешает распилить диски на разделы, и на одних частях сделать RAID-5, а на других RAID-1.

> отчего общий пул всего на ZFS становится особенно ценен.

Ну далеко не всё там так малиново, как даже вчера уже можно было сделать на LVM-2/LSR

lexa - 13/Дек/2009 14:25

Re: > взять и все пересчитать.
Да нет, я про свои теплые данные, коих одномоментно несколько сотен гигов.
То из чего они считаются - побэкаплено (преимущественно).

И проще застраховаться за 250 баксов и хорошо спать.

lexa - 13/Дек/2009 14:27

Re: > взять и все пересчитать.
А про малиновость - вот в википедии пишут, что если все диски в пуле заменить на более толстые, то пул тоже отрастет.

poige (not verified) - 13/Дек/2009 14:29

> то пул тоже отрастет.
А вот так? :-)

lexa - 13/Дек/2009 14:53

Re: > то пул тоже отрастет.
С точки зрения энтерпрайз-админа, кстати, я отсутствие возможности подрастить массив на ходу скорее приветствую. Занимайтесь, дети, capacity planning и не выпендривайтесь, а лишние ребилды - зло. И очень большое зло. Т.е. это для спасения данных, но никак не может быть запланированным дизастером. Шансы потерять RAID5 на ребилде (после аварии и замены диска) - весьма ненулевые, ну так и не надо усугублять.

Понятно, что у линуксового рынка, где ненулевое количество машин собрано из остатков, найденных в кладовой - требования совершенно другие.

poige (not verified) - 13/Дек/2009 15:03

> ненулевое количество машин собрано из остатков
Наброс, наброс. :-)

> С точки зрения энтерпрайз-админа, кстати, я отсутствие возможности
> подрастить массив на ходу скорее приветствую. Занимайтесь, дети, capacity
> planning и не выпендривайтесь, а лишние ребилды - зло.

Тенденция объяснять неудобные ограничения заботой о пользователе не нова, конечно. ;-) Но это откровенно проигрышная стратегия, поэтому даже маркетологи (особенно маркетологи?) не торопяться ею пользоваться. Ибо дети выбирают совсем другие системы, в таком случае. Что касается enterprise, то есть такое понятие, как backup. А если уж такая простая, вобщем-то, штука, как re-shape (добавление ещё одного диска в связку), настолько затруднительна для enterprise-кодеров, что шансы обос'RAID'иться сильно не-0'левые, то как же это у Neil Brown со-товарищи получилось сделать LSR, где эта же операция отлично работает, причём выживает даже после внезапного отключения питания на ходу (риторический вопрос).

lexa - 13/Дек/2009 15:10

Re: > ненулевое количество машин собрано из остатков

Я не про софт, отнюдь.

Я про наблюдение за графиком температуры дисков в ситуации, когда один диск из RAID вылетел, вставили другой и поставили ребилдится.

Что усугубляется тем, что и предыдущий диск вылетел не просто так.

Т.е. я против того, что мне дома на ZFS не дают его подрастить дотыканием одного диска и строго за то, что не могу этого никогда сделать на боевых серверах. И, главное, админ этих серверов не сможет сделать этого сам, меня не спросясь.

poige (not verified) - 13/Дек/2009 15:15

> строго за то, что не могу этого никогда сделать на бое
Ха-ха-ха. :-) Экипаж машины боевой тебе этого не простит. :-)

lexa - 13/Дек/2009 15:29

Re: > строго за то, что не могу этого никогда сделать на б
В смысле?

Любое production-железо стоит много меньше чем данные на нем (точнее, чем его функция).
Ну и в гробу я видел - если можно поставить три диска за минуту, то и поставлю, если места нет - завезу еще сервер, он за неделю окупится.

Т.е. это натурально разница между хобби (домашней машиной) и production.

В свежевыпущенном проекте железо составило меньше процента всей сметы.

poige (not verified) - 13/Дек/2009 15:36

> завезу еще сервер, он за неделю окупится.
Эээ, немного не в ту степь. Я говорил про удобство для администрирования, а ты начинаешь в духе 640 KB всегда будет достаточно, а коли нет, ещё столько же куплю . Вся соль в том, что как бы человек не предполагал, располагает не он. И вот тогда начинают рулит ср-ва, которые позволяет с меньшим гемором решить возникшую задачу.

lexa - 13/Дек/2009 15:43

Re: > завезу еще сервер, он за неделю окупится.
Грабли, лежащие на полу, обязательно будут наступлены, вопрос времени.

В этом смысле мой RAIDZ - тоже приглашение к приключению, я это отчетливо осознаю.

poige (not verified) - 13/Дек/2009 15:49

> тоже приглашение к приключению, я это отчетливо осозн
Вот-вот. :-)

lexa - 13/Дек/2009 15:53

Re: > тоже приглашение к приключению, я это отчетливо осо
Но нет способа узнать, годится ли оно у употреблению, не поиспользовав где-то.

Сам по себе концепт ZFS довольно неплох.

poige (not verified) - 13/Дек/2009 15:16

> когда один диск из RAID вылетел
Э-э-э А причём тут re-shape?

lexa - 13/Дек/2009 15:30

Re: > когда один диск из RAID вылетел
А те же яйца, вид сбоку - все данные надо переложить с N дисков на N+1.

poige (not verified) - 13/Дек/2009 15:34

> данные надо переложить с N дисков на N+1.
Да, но при этом массив не degraded.

lexa - 13/Дек/2009 15:37

Re: > данные надо переложить с N дисков на N+1.
Но имеет все шансы.

У вас температура дисков на график выведена?

poige (not verified) - 13/Дек/2009 15:46

> У вас температура дисков на график выведена?
Нет, я не такой фанат делать это дома, но у меня log'и smartd (впрочем не только smartd) в реальном времени на каждое изменение через xrootconsole рисуются. Так что как прыгает температура при нагрузке, я вижу. Так вот, если говорить про мой весьма бюджетный корпус чифтек, который сбоку ветрит из 2-х FAN'ов на массив, то никакой проблемы с температурой HDD нет вообще. Да, она плавает; сейчас она составляет ~ 33°C (при том, что FAN'ы не в полную вертятся), в среднем, а если запущу LSR'овский RAID scrub , поднимется, да, но незначительно. Вобщем, нет проблемы с температурным режимом, абсолютно.

lexa - 13/Дек/2009 15:51

Re: > У вас температура дисков на график выведена?
Речь не про дом.

Когда машина одна (или единицы), есть шансы вообще не столкнуться с тем, про что я пытаюсь говорить.

poige (not verified) - 13/Дек/2009 15:54

> Речь не про дом.
Тогда ойконечно мониторинг и всё такое. :-)

ex0_planet (not verified) - 14/Дек/2009 01:08

А в /boot/loader.conf что?
У меня zraid1 работает даже на i386/1Gb но, я бы так сказал, небыстро. И почему-то чтение из /dev/zvol/whatever сильно быстрее чем обычное чтение с ФС (это на 8.0, на 7.2 была обратная ситуация).

lexa - 14/Дек/2009 18:44

Да ничего толком нету.
vfs.zfs.vdev.max_pending=10
vm.kmem_size=3G

А в zvol небось checksums=off, оттого и быстро?

ex0_planet (not verified) - 14/Дек/2009 23:41

Нет, там on по умолчанию. Все проще на самом деле: он оказывается создает zvol как sparse file, так что это "быстро" совсем даже не быстро, а вовсе даже и медленно. Если туда что-нибудь записать, то все становится также печально как и на основной ФС.

vdev.max_pending, насколько я понимаю, влияет только на запись?

lexa - 15/Дек/2009 07:20

max_pending, как я понял, это максимальная длина дисковой очереди.

С длинной очередью на SATA - реактивность падает.

ex0_planet (not verified) - 15/Дек/2009 13:06

Реактивность реактивностью, но вот сейчас попробовал max_pending=8 и у меня заметно (раза в три) подросла скорость линейного чтения... хотя может это он лучше с торрентами параллелиться стал. В любом случае, похоже что тюнинг её - дело весьма неочевидное.

lexa - 15/Дек/2009 14:26

Да, неочевидное.

Есть сановский гайд по администрированию, есть zfs evil tuning guide, но вообще все сильно от задачи зависит.

Скажем у меня оно упирается вообще неясно во что, пишешь себе большой файл, а zpool iostat показывает 0/150M/0/150M (немного утрирую) т.е. явно набрали буфер/сплюнули буфер. Может быть в расчет чексум упирается, конечно. Итого - чуть больше 100Mb/sec на запись, для трех дисков в 'RAID5' маловато, я бы хотел 150-170

Ivan Lebedev (not verified) - 22/Дек/2009 18:38

Кстати, если вы используете WD Caviar Green Power диски, то досаждает ли вам автопарковка головок? Вроде как этот диск успевает припарковать головы за время между синхронизациями кэша. Об этом много написано в рунетах, и некоторвм саппорт предлагает отключить эту функциональность. Я в данный момент выбираю какой нибудь тихий комплект под ZFS, и хотелось перед покупкой узнать мнение здравомыслящего человека.

lexa - 22/Дек/2009 18:44

По идее, если бы оно парковалось между синхронизациями, я бы это слышал.
А я не слышу.

Но не вдавался в подробности.

Ivan Lebedev (not verified) - 23/Дек/2009 05:00

Спасибо. Да, те люди слышат щелчки. Если захочется разобраться с этим вопросом, то подробности в S.M.A.R.T. регистре Load Cycle Count.

А мне остается, только спросить, применяете ли вы для этих дисков какие-нибудь специальные параметры ZFS или hdparm. Например, какое-нибудь хитрое время очиски кэша в ZFS.

lexa - 23/Дек/2009 09:23

На трех дисках, один из которых куплен недавно (но я уже не помню - какой) Load Cycle count: 35, 43 и 22908
И у последнего - быстро растет, быстрее чем на 1 за ~30 секунд. Щелчков не слышно. Ничего не понимаю, теперь спать не буду.

/boot/loader.conf:
zfs_load="YES"
vfs.zfs.arc_max=1G
vfs.zfs.vdev.max_pending=10
vfs.zfs.prefetch_disable=1
vm.kmem_size=3G

Ivan Lebedev (not verified) - 23/Дек/2009 09:54

Благодарю вас. Обращаю ваше внимание, что у меня еще нет доказательств опасности этого явления. И вроде не все WDxxEADS так себя ведут. К тому же есть DOS утилита WDIDLE3.EXE, которая позволяет изменить значение idle3 timer'а (примерно 25 секунд) на большее. Также можно полностью деактивировать технологию IntelliPark (wdidle3 /D).

А порядок введения в эксплуатацию, можно востановить по Power_On_Hours.

lexa - 23/Дек/2009 09:58

Да, я ровно эту утилиту и применил (см. ниже).

Но у меня на дисках таймаут был 8 секунд, на всех трех.

lexa - 23/Дек/2009 09:41

Воспользовался советом отсюда: http://forum.qnap.com/viewtopic.php?f=182&t=22363

Поставил таймаут в 5 минут, счетчик на третьем диске перестал расти вроде

Почему не рос на остальных - ума не приложу.

lexa - 23/Дек/2009 09:53

Да, и судя по всему - счетчик рос на новом диске (с наименьшим power cycle count), а на двух старых - не рос. Старые купил где-то весной, новый - две недели назад.

При этом, версия фирмвари, согласно smartctl, у них одна.