Свежие комментарии

Title Comment
Теги имеет смысл пофиксить. Поменять < на &amp;lt; например

Теги имеет смысл пофиксить. Поменять < на &lt; например

Поздравляю с обновкой, ждем отчёт.

Поздравляю с обновкой, ждем отчёт.

для рулона надо брать другой на 24 или даже на 44"

для рулона надо брать другой на 24 или даже на 44"

И монитор откалибровать не забыть :-)

И монитор откалибровать не забыть :-)

А тебе рулон тоже не нужен? Я то купился на место, но руло

А тебе рулон тоже не нужен?

Я то купился на место, но рулона временами очень хочется.

тоже думаю старый продать, а новый взять, но у меня правда к

тоже думаю старый продать, а новый взять, но у меня правда крышка сверху сломана, т.ч. надо поменять сначала.

А тут появилась оказия разумно (не дорого-не дешево) продать

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

Да, неочевидное. Есть сановский гайд по администрированию,

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

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

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

нифига себе - я уже поколение пропустил - S9000 ещё печатает

нифига себе - я уже поколение пропустил - S9000 ещё печатает :)
пойду спеки почитаю твоего нового зверя

Реактивность реактивностью, но вот сейчас попробовал max_pen

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

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

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

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

Нет, там on по умолчанию. Все проще на самом деле: он оказыв

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

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

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

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

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

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

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

А в /boot/loader.conf что? У меня zraid1 работает даже на i3

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

<b>> Речь не про дом.</b><br/> Тогда <s>ой</s>конечно монито

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

<b>Re: > тоже приглашение к приключению, я это отчетливо осо

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

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

<b>Re: > У вас температура дисков на график выведена? </b><b

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

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

<b>> тоже приглашение к приключению, я это отчетливо осозн</

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

<b>> У вас температура дисков на график выведена? </b><br/>

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

<b>Re: > завезу еще сервер, он за неделю окупится.</b><br/>

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

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

<b>Re: > данные надо переложить с N дисков на N+1.</b><br/>

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

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

<b>> завезу еще сервер, он за неделю окупится.</b><br/> Эээ,

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

<b>> данные надо переложить с N дисков на N+1.</b><br/> Да,

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

<b>Re: > когда один диск из RAID вылетел</b><br/> А те же яй

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

<b>Re: > строго за то, что не могу этого никогда сделать на

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

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

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

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

<b>> когда один диск из RAID вылетел</b><br/> Э-э-э А причё

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

<b>> строго за то, что не могу этого никогда сделать на бое<

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

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

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

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

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

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

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

<b>> ненулевое количество машин собрано из остатков</b><br/>

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

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

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

Pages

Subscribe to comments_recent_new