Nest Org Ru Team Site

В продолжение раннего поста –  Solaris 11. Универсальный сервер хранения. Нюансы. – все никак не доходили руки написать.

Как верно было подмечено (см. комментарии по ссылке) – удаление ФС со включенной дедупликацией данных потенциально небезопасный процесс. Что и было подтверждено в результате производственного эксперимента. Было дано – старая V20Z на Оптеронах-248, 2 Гб памяти, два SCSI-диска (один для загрузки (rpool), другой выделенный для пула с данными). Сценарий для быстрого воспроизведения - создаем ФС (zfs create -o dedup=on -o recordsize=<ставим существенно меньше, чем 128к>storage/share).

Закидываем туда “настоящий” файл (/dev/zero – увы – не пройдет – у меня для теста были вполне себе настоящие файлы базы данных размерами всего-то по 4 гигабайта каждый) – любым удобным образом (NFS, CIFS, scp, etc). Удаляем FS (zfs destroy storage/share). Через 30 минут – zdb прекратил работать (I/O error – и точка). Через 1 час (напомню – там лежит 4 Гб данных!) – zfs/zpool команды не работают, через 1,5 часа – система пингуется, открытые ssh-сессии – “залипли”, новые сессии не открываются, консоль на движения не реагирует. Момент, когда это случилось – я (честно признаюсь) упустил. В одной из консолей был открыт vmstat 1, в другой – раз в минуту снимал состояние памяти (через mdb) – откровенного криминала не наблюдалось.

Мораль. Если планируется использовать ZFS+dedup где-то в (около)продуктивной среде – надо обязательно учесть возможные последствия при удалении ФС – для некоторых задач это НЕ критично (и я такие задачи нашел).

Мораль 2. Это надо проверить на Oracle Unified Storage 7000. Озадачился.

Мораль 3. Перезагрузка без физического отключения пула – не поможет (если что). При загрузке системы импорт пройдет автоматом, процесс продолжится без нашего участия. Феерично.

PS: шаги для быстрого воспроизведения проблемы – маловероятно, что в продуктиве будет такая конфигурация, но есть подтверждение о проблемах на нормально recordsize и конфигурации системы хранения:

zfs create -o dedup=on -o recordsize=512 storage/share
cp <amount of data greater than 2 gigs> /storage/share/
zfs destroy storage/share

В моем случае система повисла через полтора часа (Solaris 11, 2xAMD 248, 2GB RAM). На большем (правильном) блоке – объем данных нужно увеличить.

PPS: замечание “где это такой рекордсайз ты взял и это вообще не правильно!!!” – маленький хинт из man zfs:

The size specified must be a power of two  greater  than or equal to 512 and less than or equal to 128 Kbytes.

Более того – я вижу применение такого recordsize в задачах…

Сегодня в Ольгинской поднимали реактивку – ВЕЩЬ, это просто НЕЧТО. Звук просто непередаваемый, выхлоп, как у настоящего самолета. Запах авиацинного керосина – это нечто. Дома, конечно, такое держать не получится – потому идея с огромной копией отложена. Фотографий почти нет – модель не облетана, но качество аэрографии можно заценить хотя бы по этой фото – это просто ШЕДЕВР, уникальный и не повторимый:

Далее – радостные вопли белой зависти Для непосвященных навроде меня – реактивные модели – это один из самых сложных моментов в модельной авиации. Полностью повторена авионика, на борту присутствует пневматика, двойное дублирование критичных компонентов. Взлетная цена модели (если это любопытно) может легко превысить 150-200 т.р.

В этой модели двигатель со стартом на газу – то есть сначала подключается топливная линия с газом (пропаном, вроде), турбина электрикой раскручивается, подается газ в камеру – хлопок, огонь – и турбина выходит на рабочие обороты – ХХ около 30 000 об/мин, рабочий – 100 000/120 000 об/мин. Это непередаваемо – хоть и маленький, но настоящий самолет

Прокатились в Ольгинскую.

Это можно забрать на обоину рабочего стола:

Ну для разнообразия еще парочку:

Все остальное – можно посмотреть здесь.

Открыли Сезон полетушек в Ростове. Чуть поснимал.

На “пушке” я постараюсь больше не появляться – летать “под самолетами” мне не интересно и попросту страшно. Площадка, тем не менее, очень приятная – я первый раз оценил взлет с ровной поверхности – прямо-таки приятно.

Открытие для меня весьма условное – я как бы и не закрывал его, сезон этот.

PS: ну да, точно – ссылка на галлерейку.

Столкнулся с проблемой – рабочая машина – под Windows XP. Домашняя – Mac OS X. Есть масса информации, которую хочется всегда иметь под рукой, вне зависимости от местонахождения.

Примерное решение, которое нагородил для себя, состоит из нескольких (кроссплатформенных) компонентов.

С интернетом, журналами и закладками – все вопросы решились с помощью Google Chrome. Синхронизация решает все мои вопросы.

С записками (коих масса) вопрос несколько сложнее. Решение родилось следующее.
- регистрируемся на Dropbox; нам вполне хватит бесплатного эккаунта;
- ставим клиента DropBox на рабочую и домашнюю машины – доступны любые версии, и для Win, и для Mac;
- ставим TrueCrypt; успешно работает как на Win, так и на Маке;
- создаем том, контейнер – зашифрованный файл, файл размещаем в папке Dropbox’a; сейчас использую пароль, в будущем – это будет флешка с ключами (такая возможность есть); монтируем его на произвольное место – у меня это диск Y: на Win – это не важно, в действительности;
- ставим наш менеджер записочек – мне приглянулось приложение MyTetra, легкое, достаточно уродливое, поддерживает тэги и иерархию записок; настраиваем его в режиме PORTABLE – директорию корзины и данных указываем на нашем зашифрованном диске; опять-таки, эти настройки в любой момент можно поправить в файле /conf.ini (в случае PORTABLE инсталляции);

Собственно, алес – на Маке производим ряд аналогичных несложных действий и имеет профит в виде шифрованных записок

Минусы решения – на лицо – или на лице – Dropbox не синхронизирует файл-контейнер ФС, до тех пор, пока TrueCrypt не “отпустит” его.

Пост, конечно, ни о чем – но хочется сохранить линки