to post messages and comments.

← All posts tagged Linux

Завершил перенос всего и вся. Думал сделаю дня за два, получилось чуть больше двух недель.
Как же хорошо, что я когда-то давно разделил стор и апликухи. Даже самба, раздающая этот стор в отдельной виртуалке, что говорить о всяких торрентах.
Сейчас бы заколебался все это обновлять. А так переподсунул по старым путям nfs и все взлетело.

А кто умеет zfs по nfs?
У меня он сначала ругался, то fsid= не выставлен, теперь говорит что /xxx/aaa and /xxx/bbb have same filehandle for 192.168.0.0/16 using first.
И, короче, что не монтируй, получаешь содержимое только первого xxx/aaa.

Теперь вопрос стоял, какую выбрать компрессию для домашней файлопомойки.
Сравнил экстремальные варианты: недавно появившийся в zfs lz4 и gzip-9.
Lz4 в интернете поют дифирамбы, очень быстрый, хороший, жмет только то что может жать, скорость чтения и записи заметно ускоряется и т.п.
В нашей работе с виртуалками у меня очень хорошие показатели, примерно 1:2 сжатие lz4 на рабочих сторах, и примерно 1:6 сжатие gzip-5 на баккапе.

Другое дело с файлопомойкой, в большинстве своем забитой несжимаемым контентом — музыка, фото, видео, кое-какой софт.
Записав первые 2Tb инфы я получил 2% выигрыша на lz4. Честно говоря, я ожидал хотя бы 10%. Но, впрочем, тоже плюс.
А т.к. большинство инфы записывается редко, а читается то же не сказать что бы часто — решил попробовать максимум — gzip-9.
Скопировал еще раз и получил.. те же 2%! (я проверял. если писать легко-компрессируемые файлы, то все работает, разница lz4/gzip видна)
То есть на моих данных смысла в gzip нет вообще никакого. Плюс такая картина по скорости чтения/записи:
на lvm — 222/128 mb/s
на zfs с lz4 — 238/110 mb/s,
на zfs с gzip-9 — 186/10 mb/s
Ну, собственно, в данном случае gzip никак не подходит, максимальная компрессия не дает выигрыша (или дает менее 1%), но при этом скорость записи падает до 10 mb/s, что за пределами комфорта.

Вот это вообще выносит мозг тем, кто классические рейды хорошо знает:
12x 2TB:
raid10, 6x2pairs 10 terabytes ( w=569MB/s , rw=230MB/s , r=687MB/s )
raid50, 2x6raid5 17 terabytes ( w=494MB/s , rw=252MB/s , r=616MB/s )
raid50, 4x3raid5 14 terabytes ( w=459MB/s , rw=245MB/s , r=623MB/s )
24x 2TB:
raid10, 12x2pairs 20 terabytes ( w=511MB/s , rw=214MB/s , r=673MB/s )
raid50, 2x12raid5 38 terabytes ( w=492MB/s , rw=276MB/s , r=971MB/s )
raid50, 8x3raid5 28 terabytes ( w=463MB/s , rw=245MB/s , r=870MB/s )
Пятый рейд практически не отличается по скорости от 10-ки! Особенно скорость записи. Неужели они действительно победили write drawback пятого?
Я, кстати, у себя подобное наблюдал, что в raidz1 у меня не было большой разницы с 10, но точных измерений провести не успел.

А у кого-нить есть идея, почему у меня на одной системе у одного файла постоянно меняется crc?
changed file : /usr/share/man/man3/netsnmp_table_dataset.3.bz2
2015/08/02 03:12:30 md5: o6dSN/2g0SzpscRYX+poJw — GYStUMSPmOgW+HKyRzLaBQ
2015/08/09 03:12:26 md5: GYStUMSPmOgW+HKyRzLaBQ — 7DjTCqKiMqux8RAzX74Pcg

Очень полезные бенчмарки zfs в различных конфигурациях дисков и рейдов calomel.org
На многодисковых конфигах видно, что не смотря на заявления, что скорость растет только в страйпах, на raidz(1,2,3) она то же неплохо растет.
Так что можно увеличивать трансфер добавляя дисков, а не увеличивая кол-во vdev.

Получилось на zfs провести фокус с созданием raid5 массива только на 2 дисках из трех, как я привык это делать на mdraid.
Делается фейковый фаил, который занимает пару килобайт, но репортит полный размер:
# dd if=/dev/zero of=/tmp/disk.img bs=1 seek=4T count=1
создаем пул:
# zpool create poolA raidz1 /dev/sda /dev/sdb /tmp/disk.img
и фейк сразу выводится в оффлайн, что бы туда ничего не начало писаться:
# zpool offline poolA /tmp/disk.img
Все, имеем пул в дегрейде из 2 дисков, можно залить данные, высвободить еще один диск и добавить к пулу, после ресильвера будет ок.

Вечером таки закончился ребилд, так что я вынул пару винтов с бедами и прокатился до юлмарта.
Пессимистично получилось, старой базы серийников у них нет в нерабочее время, но гарантия на такие винты должна быть около 2 лет, по словам товарища на приемке.
Если это действительно так (поищу сегодня чек), то я попал на два 2tb винта.
Посмотрел за одно ценник текущий — 6.5-7 тыр за винт! Это 13-14 тысяч. Помнится покупал я их чуть ли не по 2.5 тыр.

А вот хрен. Снял я копию скажем с sdb (диск из mdraid) с помощью ddrescue, потом залил обратно на этот же винт (успешно!), ставлю на ребилд — опять ошибка:
kernel: blk_update_request: critical medium error, dev sdb, sector 399482128
kernel: raid5_end_read_request: 4 callbacks suppressed
kernel: md/raid:md127: read error not correctable (sector 399449432 on sdb1).
kernel: sd 4:0:11:0: [sdb] UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
kernel: sd 4:0:11:0: [sdb] Sense Key : 0x3 [current]
kernel: sd 4:0:11:0: [sdb] ASC=0x11 ASCQ=0x0
kernel: sd 4:0:11:0: [sdb] CDB: opcode=0x28 28 00 17 cf 9d 10 00 00 50 00
kernel: blk_update_request: critical medium error, dev sdb, sector 399482128
kernel: md/raid:md127: Disk failure on sdb1, disabling device.\x0amd/raid:md127: Operation continuing on 2 devices.
kernel: md: md127: recovery interrupted.

Теперь придется идти долгим путем. Запускаться с копии а битые винты попробовать вернуть в юлмарт.

Сделал копию дисков с ошибками из рейда mdadm на новые диски через ddrescue. Скорость 2тб за 12 часов, но за то параллельно можно что-то делать.
Потом решил, что зря пропадать и залил эти данные поверх обратно на старые винты. При перезаписи сбойные сетора должны бы отремапиться.
Делал через стандартный "dd if=... of=... bs=1M". Скорость 2тб за 6 часов, но за то только один процесс в системе живет, все остальное в фризе. Он их sync'ом что-ли гонит по дефолту?

Так, 10 часов на dd_rescue на 2tb, 10 часов на ребилд mdadm 2tb, (тут место для еще одной итерации, если еще один диск взбрыкнет), ~30 часов на копирование 6Tb на временный zfs, ~30 часов на копирование обратно на переделанный zfs.
Итого — неделя и золотой ключик у нас в кармане.

Утром, вместо душа, я рекомендую вам принимать
kernel: blk_update_request: critical medium error, dev sdb, sector 360745792
kernel: Buffer I/O error on dev sdb, logical block 45093224, async page read
kernel: md/raid:md0: Disk failure on sdb1, disabling device md/raid:md0: Operation continuing on 2 devices.
kernel: md: md0: recovery interrupted.

ЗЫ Шучу. Обычное дело, сдох диск, во время ребилда вылетел еще один. Натравливаем dd_rescue, перепихиваем другие диски в md0 принудительно, ребилдим.
Рутина, но перенос данных чувствую затянется на всю неделю.

Создал пул из 3 дисков, поставил копироваться с lvm на zfs.
Вижу четко, как zfs упирается в скорость одного диска. Один постоянно висит с io 200-500, трансфер 40-100mb/s, остальные два раз в 4 секунды пишут 700 io 60-100mb/s и тишина.
Диски хорошие, новые. Контроллер sas один, отдельный канал до каждого диска.
Может еще как подтюнить стоит?

Задумал переделать домашнюю файлопомойку на новые диски, за одно переведя с lvm на zfs.
С ужасом подсчитал, что 6тб даже с идеальной скоростью 100mb/s будут копироваться 17 часов.
А в реальности скорость у меня будет поменьше.
Грусть-печаль, все мои домашние сервисы будут остановлены сутки или более.

А кто-нибудь знает хороший ftp-сервер, который умеет 3 ключевые фичи:
— анонимусов пускать на чтение (это вроде все умеют)
— шейпить канал (отдавать не более X мбит)
— лимитировать кол-во сессий с 1 ip.
Вот, например pureftp отлично лимитирует кол-во сессий, но вроде нет шейпинга. Шейпинг есть в proftpd, но, как оказалось, один неадекват запросто открывает полсотни сессий, полностью выжирая все ресурсы и игнорируя кол-во сессий в конфиге.

Чем больше я работаю с zfs. тем больше она мне нравится.
Даже по сравнению с lvm.
Даже думаю не поставить ли через ZoL его на свои машины (на root для виртуалок, на рейд-диски на файлопомоке).
Единственное, что меня не устраивает с т.з. домашней файлопомойки — отсутствует механизм удаления винта из пула.