root on ZFS

Для тонких ценителей.
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

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

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

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

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

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

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

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

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

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

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

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

> жесткая перезагрузка с 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На трех дисках, один из которых куплен недавно (но я уже не помню - какой) 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

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

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

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

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

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

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

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

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

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

Add new comment