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

> Цена такой скорости - примерно 400Mb kernel memory
Хренассе. У LSR и с этим всё значительно приятнее! :-)

> Несколько странно, что скорость чтения оказалась мен
http://poige.livejournal.com/258717.html

это, кстати, на RAID-контре было дело.

Кстати о корпусах! Ты не исследовал вопрос корпуса домой под RAID? У меня сейчас чифтек, там 6xHDD внутри, поперёк, с вентиляторами тоже поперёк (от боковй стенки к боковой). Всё бы ничего, но что-то хочется хот-свапа, т.е. внешних корзин. На 6 дисков. Не в стойку... Хм. Ничего такого не видел? И что бы винты хоть как-то обдувались...

Проблема с батарейкой в том, что в 1U-корпус ее часто некуда запихать. Просто нет места.

А вообще, сейчас 1U корпус с процессорами и прочими потрохами обойдется небось штуки в полторы-две (без дисков), а то и меньше. И диски еще в 700. На этом фоне 500-600 за 4-портовый контроллер - заметно.

Т.е. у меня цель скорее исследовательская - посмотреть что за жилец этот raid5 (до того был ZFS, на 32-битной FreeBSD - не жилец). Потому что сама по себе идея - благородная "зачем платить больше".

Вопрос про разваливание (лень доставать и выдергивать диск, хотя надо конечно попробовать) такой - вот оно сейчас уже
raid5/data REBUILDING CALM ad1 (130544697344 / 17% (p:7003))

Если я пойду и из CALM вытащу диск - то что будет?

А с RAID без батарейки ситуация очень простая - то, что synced на диск - уже там (мимо кэша). То что не synced - ситуация в точности такая, как с одним диском - что-то могло недозаписаться, состояние этого блока неопределенное, нужно fsck. Ну вот разве только "блок" получается побольше.

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

Во всяком случае, я себе это именно так понимаю. И никогда нажатие ресета/питания не ведет к полному ребилду.

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

б) всякий продакшн. Веб-сайт или поисковик или база данных и т.п. Ситуация, когда пропадание питания ведет к многочасовому fsck и/или ребилду - категорически неприемлема. Питание имеет тенденцию пропадать целыми стойками (и залами), подниматься после такого сутки - очень не хочется. Поднимать veri_nice - еще больше убивать перформанс.

От fsck спасает (в теории) журнал. Пока не пробовал (вообще никогда), наверное завтра вечером попробую, как раз поребилдится, 8 часов осталось (veri_nice поднял, может и за 4 справится).
А от ребилда - похоже ничего не спасает (кроме настояшего контроллера)

Ну и мне кажется, так рассуждая, gjournal вообще должен убивать производительность :)

P.S. Блин, дёшево же ты ATTO взял... правда мне фигли толку -- FreeBSD их не поддерживает :(

Я использую -eff в продакшн. Во-первых, можно ценой замедления "нормальной" работы ускорить ребилд примерно в четверо:

kern.geom.raid5.veri_nice=0
kern.geom.raid5.veri_fac=1000

Во-вторых, я настраивал -eff (-pp хуже на чтение, чем -eff настраиваетс,Я автор в недоуменни, но эффект подтверждает) на твои скорости при вдвое более медленных дисках ;-)
Примерно так:

kern.geom.raid5.maxmem=80000000
kern.geom.raid5.maxwql=200
kern.geom.raid5.wdt=5

В третьих, оно у меня уже разваливалось аппаратно. Всё восстановило. Дважды-фейл -- да, скорее всего умрёт.

А как аппаратные массивы БЕЗ БАТАРЕЙКИ решают проблему ресета, а? Вроде как он тоже обязан начать ребилдится в такой ситуации.

Да, gjournal пробовал, не понравилось.

Леха, мегабайт сокращается как MB (http://en.wikipedia.org/wiki/Megabyte), а не как Mb, что означает мегабит. То же самое верно для остальных байтов/битов.

Ага, вроде так. Похоже, я чего-то неправильно насчитал.

Мы с вами забыли очень важное соображение, которое всю картинку резко изменяет: <b>цветовой шум вообще не волнует, волнует яркостный</b>, в реальной жизни каналы цветности можно вообще размыть с довольно большим радиусом и картинка не пострадает.

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

Соответственно, расширение спектра пропускания фильтров от "RGB" в сторону панхроматических - шум в "яркостном канале" (например в Y) будет очевидно уменьшать.

Об том не знал. Спасибо, посмотрим.

Действительно, на двух компонентах проще думать.

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

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

Приветствую!

Пришёл по линку из упомянутой ниже ветки на forum.ixbt.com (меня там зовут очень страшно, напоминание из далёкого детства, <a href="http://forum.ixbt.com/users.cgi?id=info:BlackLor%20%28Pell%29">BlackLor (Pell)</a>). Надоедать не буду, просто приведу (очень грубый) пример относительно

<em>> недиагональная часть матрицы может и расти (не могу представить в уме&hellip;</em>

Кросс-постинг <a href="http://forum.ixbt.com/topic.cgi?id=20:25524-7#153">отсюда</a>:

<blockquote>Простая двумерная модель. Есть две величины условно назовём их зелёная R и красная R . Когда Вы измеряете их линейную комбинацию g*G+r*R при помощи одной зелёной линейки и одной красной линеек, то Вы получаете (g g^1/2)*G+(r r^1/2)*R. А если Вы, в погоне за большими абсолютными значениями сигнала, использовали одну зелёную и одну зелёно-красную (измеряющую сумму r+g) линейки, то намерили бы (g g^1/2)*G + (r+g (r+g)^1/2)*(R+G). Итого, шумов в зелёном канале ровно столько же (красный в зелёный не затекал), а в красном приходится вычислять разность между величинами: (r+g (r+g)^1/2) - (g g^1/2) = r (r+g)^1/2 g^1/2. При соизмеримых уровнях сигнала в каналах R и G получили очевидное усиление шумов в красном канале в примерно 2.4 раза. Оно нам нужно?</blockquote>

В общем случае, очевидно, нужно вычислять ковариационную матрицу, что в голове без бумаги уже, увы, не помещается.

Конечно же, Ваши доводы о дополнительными проблемами с ухудшением цветоразличения при неумеренном уширении спектральной полосы пропускания микролинз в погоне за ОСШ <u>для данного конкретного пикселя</u> остаются в силе.