Nest Org Ru Team Site

Съездили на базу “Мечта” (хутор Махин, и далее по безумной дороге). Без комментариев

Коллективно наблюдали сегодня занятное явление – Гало вокруг Солнца – выглядит необычно

Товарищ не подвел и был с фотоаппаратом (в отличии от меня):

All rights reserved by ait

Выглядит необычно!

PS: вариант происходящего от автора фото – http://www.atoptics.co.uk/droplets/corona.htm – Ice Coronae.

Я “занастраивался” Оказалось проще начать все с нуля, чем выискивать – чего я там наизменял.

Для сброса в заводские настройки GV-1: передатчик включен, борт выключен. Удерживайте одноврменно кнопки FUNC+/FUNC-, включите борт. Экран помигает около 3-х секунд, отпускаем кнопки. Нажимаем кнопку FUNC+, пока на экране не появиться надпись RESET. Единожды нажимаем DATA+, будет задан вопрос “вы уверены?”. Нажимаем DATA+ еще раз – вуаля, заводские настройки восстановлены.

Via Freestyle 3D.

We are all very excited about the 18MZ. Next week we will begin to post more details about it and FASSTest the Futaba telemetry system. With FASSTest, no extra telemetry box is required, it is all built-in and uses S.Bus2 for communication.

мы очень рады бла бла 18mz. На следующей неделе начнем раскрывать детали про нее и телеметрию от Futaba FASTest. С FASTest никаких дополнительных девайсов – не нужно, все уже встроено и использует S.Bus2 для связи.

С официальной страничке на facebook’e! Ура!

Немного фото со встречи.

Остальное здесь.
Тем временем говернер настроен, мотор запел Осталось “поумнеть” самому

В продолжении вот этого поста.

При восстановлении снимка на другой машине через ssh (rsh аналогично) нарвались на проблему с низкой пропускной способностью всего комплекта (zfs send, ssh, zfs receive). Быстрый анализ привел к этой дискуссии.

Проблема хорошо описана здесь – zfs receive имеет характер “пульсирующей” нагрузки (bursty) – приняли блок, чего-то делаем и перевариваем, zfs send в это время фактически простаивает (хотя – оба процесса могут давать пропускную способность много больше – просто у одного не забирают, а другой не принимает данные потоком, “забивая” сеть – получается ситуация, когда все компоненты могут существенно больше, чем есть на деле).

Решение – в том же блоге – описано довольно неплохо – надо буферировать приемо-передачу. Для этих целей создана утилита mbuffer. Небольшое клиент-серверное приложение, создающее буфер заданного объема с заданным размером блока внутри.

Успешно собирается (товарищ подтвердит) на Solaris 10, можно и пакеты поставить готовые.

Использование:

# принимаем поток
[root@server2]# mbuffer -s 128k -m 1G -I 9090 | zfs receive datapool/fs1
# отправляем поток
[root@server1]# zfs send datapool/fs1@pipesnap | mbuffer -s 128k -m 1G -O 10.0.0.1:9090

На мой вкус – чистый профит – выигрываем почти 10х приростом производительности!

К сожалению, эти механизмы как-то странно обходят собственно в Solaris 10/11 (по крайней мере – очевидного решения я не нашел).

PS: http://truewaytags.blogspot.com/2011/05/zfs.html – а вот и товарищ по несчастью

Доступен. Почитать можно здесь.
- Новый BUI – весь такой занятный и не красный (что странно).
- Новый инсталлятор (utsetup).
- поддержка USB-гарнитур
- оптимизация аудио-потоков
- поддержка IPMP на shared network (позитив)
- выкинули GUI Firmware.
- новый процесс загрузки собственно Sun Ray – стал более user freindly
- расширен список поддерживаемых смарт-карточек

Теперь официально – поддерживается только Solaris и Oracle Linux (goodbye, Redhat! Фактически, полагаю, будет успешно работать и на RHEL – и производными – CentOS и т.д.). Выкинута поддержка USB to serial.

Короче – к зачтению это обязательно – Sun Ray Software 5.2 Release Notes.

Надо будет придумать способ обновиться

PS: и тут – вопрос – “и где клиент для iPad?”
PPS: Press Release.

Известно, что Veritas NetBackup умеет бэкапить (и восстанавливать) именованные каналы (named pipes, пайп(ы) дальше по тексту). Этим и воспользуемся.

Дано: файловая система ZFS, около 1 Тб в объеме, около 2-х миллионов файлов на ней, небольшого размера – 200-400 Кб. каждый. Для понимания – сделаем ls -la внутри этой директории, подождем. Много – и долго.

Надо: изготовить резервную копию этой ФС. Обычный бэкап работает очень медленно (tar, bpbackup) – около 12-18 часов на одну ФС, поток в 4-8 Мб/c – неприменимо, лента занята слишком долго одним заданием. Скорость модификации составляет около 800 Мб-1Гб/сутки по предварительной оценке (добавляются новые файлы). Что делает применение обычного файлового бэкапа вообще малореальным. Задачи восстановления единичного файла с ленты – не стоит. Предполагаем, что политики у нас уже настроены…

Делаем:
- создаем снимок ФС (по хорошему – надо перестраховаться и “притормозить” приложение, но – нам известен регламент записи заранее – и потому этого мы делать не будем, занимаясь изготовлением снимка в подходящий момент)
- создаем пайп
- запускаем процесс отправления снимка
- запускаем процесс бэкапа (в нашем случае NB bpbackup)
- ждем окончания процесса
- удаляем пайп
- удаляем снимок

zfs snapshot datapool/fs1@pipesnap
mkfifo /tmp/pipesnapGate
zfs send datapool/fs1@pipesnap > /tmp/pipesnapGate &
bpbackup <ключи NB> -w /tmp/pipesnapGate &
wait
rm /tmp/pipesnapGate
zfs destroy datapool/fs1@pipesnap

Скорость – 50-80 Мб/c – на порядок лучше, чем стандартными средствами. Очевидный минус – из архива проблематично достать единичный файл.

Как всегда – бэкап без восстановления – пустое место. Если надо – нарисую последовательность команд для восстановления. Она такая же простая. Вдумчивое “курение” документов позволит отказаться от запуска скрипта на стороне сервера.