blog.lexa.ru

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

На полке в шкафу, дверца приоткрыта, верхний выдув корпуса смотрит на улицу, система активно эксплуатируется (3Tb файлов выливаются с временного стораджа туда):

• Диски: 35-39 градусов (новые WD RE4 греются меньше и они 35, старые сигейты - 39).
• Процессор: 40-45
• RAID-контроллер: 63

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

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

Корпус: Lian Li PC-A04. Впрочем, PC-V354 стоящий в том же шкафе полкой выше - ведет себя примерно так же. Но он побольше немного.

Вот, померял на досуге:

• ASR-5805, 8 дисков в RAID-6, 2Tb-раздел в начале массива. Тестируем гигабайтным блоком, 40 гигов чтения/записи:
  • NTFS (Win7): 651Mb/sec чтение, 651Mb/sec запись.
  • UFS2+SUJ (FreeBSD 9.1): 585Mb/sec запись, 528Mb/sec чтение.
  • EXT4 (Ubuntu Server 11.10): 659/639
• ZFS RAIDZ2 (FreeBSD 9.1), те же 8 дисков: 490Mb/sec на запись (dd bs=1024M), огорчился и не стал мерять дальше.

Так как эти ~650Mb/sec у меня из Убунты впрямую транслируются в SRP (SCSI RDMA Protocol), то я уже счастлив (подробности чуть позже).

Hardware: Intel i5-2400, мамка на Z77, 8GB RAM, Adaptec ASR-5805, 6 дисков Seagate Barracuda ES.2 1Tb (SAS), два диска WD RE4 1Tb (SATA). Размер блока массива - 256Kb. Никаких моментиков с терабайтниками (вроде 4-к сектора) - нету.

Да, ZFS куда более удобная в использовании: нет многодневных ребилдов массива, можно менять диски в RAIDZ на бОльшие (и после замены всех - емкость вырастет), снэпшоты и все такое. Опять же, Verify так не просаживает производительность, сплошное счастье.

Но мне для дискового ящика от ZFS нужно только тома нарезать - и терпеть на этом фоне разницу в перформансе в 1.3 раза я не готов.

А вот у меня в FreeBSD, еще с гигабитных времен написано такое вот, к примеру:

net.inet.tcp.recvbuf_auto=1
net.inet.tcp.recvbuf_inc=131072
net.inet.tcp.recvbuf_max=1048576
net.inet.tcp.sendbuf_auto=1
net.inet.tcp.sendbuf_inc=131072
net.inet.tcp.sendbuf_max=1048576
net.inet.tcp.maxtcptw=102400

Ну и так далее, конкретные слова я брал, кажется, из какой-то презентации Сысоева. И работает, на 10G-сети Samba практически упирается в диски, насколько я вижу.

Вопрос: где взять готовых рецептов для тюнинга Linux? Задача - максимальный перформанс у самбы. А то сейчас смешно: запись 560Mb/sec, а чтение - 235, это же явно сеть не того, а не диски. dd гигабайтными блоками пишет 660 Mb/sec, а читает - 640.

Если существенно: Ubuntu Server 12.04, 3.2.0-29-generic #46-Ubuntu SMP. Intel Core-i5 2400, 8GB RAM.

Наткнулся в ЖЖ Ильи Борга на такой вопрос к нему:

Я уточнить хотел к предыдущему вопросу. В MF цифровых камерах согласно всяким там заявленным характеристикам вроде часто стоит 16 битный АЦП. Это якобы заметно повышает ДД камеры (настолько что как обсуждалось некоторыми товарищами в той ссылке оставляет все DSLR с ихними 14 битами далеко позади). Это действительно так? Какй нибудь сильный выигрыш в тенях от этого получается?

Так вот, вот вам ответ для PhaseOne (компрессированный формат): Если простыми словами, то в pixel[] содержится распакованая (из хаффмана) строка, дальше значение пиксела сдвигается на два бита (умножается на 4), потом вычитается уровень черного и все это кладется в 16-битный (unsigned short) буфер.

Какой вывод мы можем сделать? А такой, что АЦП - 14-битный, а в младших битах 16-битных значений до вычитания черного были такие вот кругленькие нолики.

В нежатом формате - не так, но нежатый формат я видел только на очень старых задниках, а все что видел нового - жатое. И на P45 и на P65+ и на IQ180 - везде в данных 14 реальных бит.

Справедливости ради, в материалах на сайте PhaseOne ничего про 16-битный АЦП не написано. Все гораздо более обтекаемо, "16-bit OptiColor"...

P.S. Написанное выше - конкретно про PhaseOne. Невозможность имения в этом формате 16-битных RAW-данных вытекает просто из процедуры распаковки. Для других форматов все не так прозрачно.

По сложившейся традиции, анонсирую LibRaw 0.15 Alpha2.

Изменения относительно альфы-1:

• Кроппинг и отдельный вызов LibRaw::subtract_black() полностью работоспособны (в альфе-1 это было не так).
• Исправлена генерация тоновой кривой для lossy DNG, теперь она полностью совпадает с таковой у dcraw (в альфе-1 временами было расхождение в младшем бите).
• Вместо поканальных максимумов данных (color_data.channel_maximum) сейчас рассчитывается общий максимум (color_data.data_maximum). Для коррекции розовых облаков этого достаточно.
• Компрессированные файлы PhaseOne распаковываются в raw-буфер полностью "как есть", коррекция по метаданным из файла (замазывание плохих пикселов, вычитание черного) идет на этапе постобработки или в raw2image(). Если вдруг кому нужны полностью неизмененные данные с этих задников - вот они, пользуйтесь.
• Импортирована свежая dcraw, поддержка Samsung NX-1000 и Sony DSC-RX100.

Спешу сообщить, что ветка 0.14 развиваться далее не будет, если нужна поддержка новых камер, то используйте 0.15. "Альфа" в названии означает на сегодня только нестабильность ABI (и в меньшей степени - API), а в смысле реальной жизни - все (вроде бы) довольно стабильно.