суббота, 30 мая 2009 г.

Oracle, Solaris, ZFS и свободная память

Насколько в действительности велики требования по оперативной памяти у ZFS при реальной работе?

Sun говорит, что нужно впридачу к требованиям системы и приложений еще минимум 1 Гб.

В принципе, верно. На машинах всего с 1 Гб оперативной памяти действительно ZFS хорошо не работает, а с Ораклом есть недурные шансы вообще что-то не запустить.

Впрочем, "Вж-ж-ж-ж-ж! - сказала пила, - Ага-а-а-а! - сказали мужики" - надо быть полным 8-5, чтобы, вопреки законам сохранения реального мира пытаться заставить работать подобное при практическом отсутствии ресурсов (хотя, как ни странно, такие находятся с завидной регулярностью, пытаясь пилить пилой, например, лом - и исходя криком "Мастдай!" когда выясняется, что это невозможно. Откуда берутся такие личности - сие мне неведомо, по идее, рождаться они не должны вообще - однако их, видимо, просто мечут как икру).

Давайте немного разберемся, как и почему ZFS используем память и - самое главное - как много?

Если Солярис стоит на UFS, то память, которая идентифицируется системой как свободная, в действительности занята - кэшами файловых систем. Если только они не смонтированы с опцией direct IO.

Оракл в этом случае при малейших огрехах в конфигурации инстанса работает достаточно медленно - и это мягко сказано.

Хотя двойное кэширование и считается злом, прямое монтирование (либо использование raw devices) либо дает мизерный выигрыш (в сравнении с очень осложненным администрированием) либо не дает его, а иногда и вовсе выигрыш оборачивается проигрышем.

Чекпойнтинг кэшей UFS выполняется достаточно часто, чтобы не беспокоиться о целостности БД. Причем планировщиком ZFS выполняется аггрегация записей в кэше, и сброс множества мелких записей одной пачкой, как во многих реляционных СУБД (хочу напомнить параметр db_file_multiblock_read_count в Оракле. От его максимизации растут ноги у уменьшения отклика БД в определенных конфигурациях - что физически не знают большинство DBA).

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

В случае с ZFS кэши нужны в значительно большей степени.

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

Ключевым словом является термин ARC. Цитирую дословно один из первоисточников: The ZFS adaptive replacement cache (ARC) tries to use most of a system's available memory to cache file system data. The default is to use all of physical memory except 1 Gbyte. As memory pressure increases, the ARC relinquishes memory.

Замечание: Сразу становится понятно, откуда взялось требование +1 Гб.

Фактическое двойное кэширование в данном случае во-первых, не ведет к повышению вероятности нарушения целостности БД в силу транзакционной семантики ZFS и наличию ZFS Intent Log – ZIL), а во-вторых, не снижает производительности, так как даже на UFS/JFS отключение write behind кэша фактически зарезает производительность записи до абсолютного минимума. Посему кэширование напротив способствует повышению скорости записи или чтения.

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

Замечание: Некоторые трахнутые маньяки почему-то считают, что полное отсутствие дополнительного кэширования, особенно в сочетании с raw devices, имеет бешеное преимущество по скорости. Тут следует заметить, что, во-первых, не бешеное, а всего лишь 10-15%. Интересующихся, кто это сказал, отсылаю читать трахнутый оракловый мануал Performance Tuning Guide, особенно его приложения. Во-вторых, такие джентльмены волокут БД на raw devices, напрочь игнорируя тот факт, что даже эти 15% они могут получить лишь при адекватном тюнинге инстанса и, в особенности, при выставлении величины предвыборки Оракла в максимум, и, перед этим, такой же установки на уровне ОС и ее драйверов SCSI. В остальных случаях маньяки по заслугам получают усложнение администрирования до предела, холодный физический бэкап средствами dd а также отсутствие сверхзвукового выигрыша и, благодаря этому, проводят время не за пивом-ца-ца, а за консолью, в ожидании завершения процесса. :) Ах, обманули! Где быстрая работа баз данных? Где вообще скорость дисковой системы? Как посекторно? Ой, восстанавливать физический бэкап посекторно?! Нам не сказали! То есть как ASM и RMAN? Мама, роди-ка меня обратно!

Вернемся к нашей теме.

Итак, при использовании ZFS свободная память остается в разных количествах.

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

Взгляните на прокси-сервер, который находится исключительно на ZFS и у которого кэшируется огромное количество мелких файлов:

last pid: 430; load avg: 0.00, 0.00, 0.00; up 0+02:15:52 15:52:39
40 processes: 39 sleeping, 1 on cpu
CPU states: 99.2% idle, 0.2% user, 0.6% kernel, 0.0% iowait, 0.0% swap
Kernel: 96 ctxsw, 320 intr, 171 syscall
Memory: 2043M phys mem, 1640M free mem, 2048M total swap, 2048M free swap

PID USERNAME LWP PRI NICE SIZE RES STATE TIME CPU COMMAND
247 root 4 54 0 25M 21M sleep 0:02 0.29% named
430 root 1 1 0 2992K 1828K cpu 0:04 0.07% top
382 squid 1 1 0 16M 13M sleep 0:04 0.05% squid
401 root 1 100 -20 2556K 1296K sleep 0:00 0.01% xntpd
398 root 1 59 0 7884K 3400K sleep 0:00 0.00% sshd
7 root 12 29 0 11M 8820K sleep 0:02 0.00% svc.startd
383 root 1 1 0 11M 4788K sleep 0:00 0.00% httpd
109 root 1 1 0 2700K 708K sleep 0:00 0.00% ipmon
9 root 14 29 0 10M 9192K sleep 0:08 0.00% svc.configd
235 root 1 1 0 1432K 640K sleep 0:00 0.00% utmpd
236 root 18 1 0 12M 9124K sleep 0:01 0.00% fmd
404 root 1 1 0 3056K 2072K sleep 0:00 0.00% bash
65 root 6 1 0 3620K 2036K sleep 0:00 0.00% devfsadm
378 root 12 1 0 4016K 1872K sleep 0:00 0.00% syslogd
1 root 1 1 0 2492K 1428K sleep 0:00 0.00% init

Данная машина имеет безупречную скорость отклика (разумеется), запускает процессы и вообще чувствует себя хорошо.

Что касается кэширования крупных файлов при небольшом их количестве, например, оракловые БД, то здесь картина другая. Свободной памяти реально мало:

load averages: 0.05, 0.07, 0.10; up 0+02:43:14 15:54:49
73 processes: 72 sleeping, 1 on cpu
CPU states: 99.3% idle, 0.3% user, 0.4% kernel, 0.0% iowait, 0.0% swap
Kernel: 205 ctxsw, 443 intr, 174 syscall
Memory: 4096M phys mem, 147M free mem, 8192M total swap, 8192M free swap

PID USERNAME LWP PRI NICE SIZE RES STATE TIME CPU COMMAND
7124 root 1 59 0 3912K 2224K cpu/0 0:00 0.13% top
494 oracle 1 59 0 0K 0K sleep 0:07 0.10% oracle
4837 oracle 1 59 0 0K 0K sleep 0:02 0.06% oracle
4839 oracle 1 59 0 0K 0K sleep 0:07 0.05% oracle
4814 oracle 32 29 10 268M 146M sleep 6:08 0.05% java
490 oracle 11 59 0 0K 0K sleep 0:12 0.04% oracle
474 oracle 1 59 0 0K 0K sleep 0:06 0.03% oracle
484 oracle 20 59 0 0K 0K sleep 0:14 0.03% oracle
5131 oracle 1 59 0 0K 0K sleep 0:08 0.01% oracle
203 root 13 59 0 164M 30M sleep 0:04 0.01% java
480 oracle 200 59 0 0K 0K sleep 1:59 0.01% oracle
136 root 6 59 0 4736K 2280K sleep 0:01 0.01% picld
5104 oracle 7 29 10 38M 29M sleep 0:16 0.01% emagent
482 oracle 15 59 0 0K 0K sleep 0:59 0.00% oracle
512 oracle 3 59 0 0K 0K sleep 0:01 0.00% tnslsnr

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

Как и было сказано у первоисточника: The ARC is where ZFS caches data from all active storage pools. The ARC grows and consumes memory on the principle that no need exists to return data to the system while there is still plenty of free memory. When the ARC has grown and outside memory pressure exists, for example, when a new application starts up, then the ARC releases its hold on memory. ZFS is not designed to steal memory from applications. A few bumps appeared along the way, but the established mechanism works reasonably well for many situations and does not commonly warrant tuning.

Более того, данную машину крайне сложно заставить свопиться. Хотя EM на ней и ругается на то, что память занята по самые не улыбайся и шлет алерты почтой:

Name=hostname.domain.com
Type=Host
Host=hostname.domain.com
Metric=Memory Utilization (%)
Timestamp=May 30, 2009 3:43:29 PM ALMT
Severity=Critical
Message=Memory Utilization is 95.78%
Rule Name=Host Availability and Critical States
Rule Owner=SYSMAN

Ну, коль скоро нетрудно убедиться, что этот алерт в случае ZFS вовсе не повод для тревоги, стоит повысить величину metric thresholds, чтобы не беспокоил:


Обратите внимание, что никакой перегрузки нет и в помине. Процессор холодный, и, более того, как только вы возжелаете, скажем, запустить или остановить EM (весьма прожорливый по памяти), то обнаружите, что запускается он без единой проблемы, при остановке же память освобождается - ненадолго - а потом ее использование поднимается до прежнего уровня.

При этом прошу также обратить внимание, что Оракловая БД работает как часы - без единой задержки.

Напоследок обращаю внимание маньяков, что в обеих вышеприведенных примерах не используется raidz или, тем более, raidz2. Здесь это говорится буквально: For better performance, a mirrored configuration is strongly favored over a RAID-Z configuration particularly for large, uncacheable, random read loads. А здесь объяснено в деталях, почему. Не менее внятно объяснено у первоисточника.

PS. Настоятельно советую маньякам прочесть также здесь, здесь и здесь.

среда, 27 мая 2009 г.

Подкачка и дамп в ZFS root pool

В некоторых случаях миграции с UFS на ZFS посредством Live Upgrade возникает необходимость полностью освободить устройство, на котором находился UFS boot environment.

На практике, однако, иногда возможно столкнуться с ситуацией, когда мигрировать приходится дважды. Скажем, по схеме UFS BE->old ZFS BE->new ZFS BE. Например, для последовательной миграции сначала на ZFS root pool и последующего апгрейда ОС с возвращением ее на первоначальный жесткий диск уже с другой файловой системой. Особенно если второй и третий шаг выполняется со слайсами 0 на весь объем дисков.

При этом иногда происходит следующее. Первый переход выполняется сравнительно беспроблемно, однако при попытке удаления старого root pool происходит ошибка - dataset busy.

Если посмотреть на содержимое файловых систем ZFS, можно заметить, что на старом томе остались dump и swap устройства. Причем на новом rpool их нет.

Попытка избавиться от занятости датасета, в общем, удается. Перезапускаем систему, стартуем ее с нового rpool - вуаля, старый rpool удаляется.

Однако новая система неожиданно оказывается без подкачки и dump-устройства.

# swap -l

показывает, что подкачки нет. Ой, что это? Как это исправить? Солярис без подкачки долго не проживет и упадет от любого самого легкого пинка.

Первым это обнаруживает Oracle - он начинает стартовать необычно долго.

top показывает отсутствие подкачки в принципе.

Можно ли в такой ситуации что-нибудь втереть, или вправить или еще что-нибудь?

Оказывается, можно.

Перво-наперво, идем сюда и читаем мануалы:

Номер 1
Номер 2

Что из них следует? Следует то, что можно (и нужно) попробовать создать датасеты для подкачки и дампа и присоединить их к работающей системе и действующему rpool.

Как это сделать?

Сначала создадим dump:

zfs create -V 4G -b 128k rpool/dump

(для примера - в нашей системе 4 Гб ОЗУ, отсюда размер датасета - кстати, его можно на ZFS rpool легко изменить, если, разумеется, есть свободное место)

Далее, используя dumpadm, добавляем созданный датасет как дамп-устройство в действующий root pool:

# dumpadm
Dump content: kernel pages
Dump device: /dev/zvol/dsk/rpool/dump (dedicated)
Savecore directory: /var/crash/athena

используя в качестве целевого устройства вот это логическое имя: /dev/zvol/dsk/rpool/dump

Замечание: Можно не добавлять дамп-датасет в /etc/dumpadm.conf. Как показала практика, его достаточно создать с именем <имя rpool>/dump, перезагрузиться и он будет подключен к системе автоматически.

Далее создаем датасет для подкачки:

# zfs create -V 8G -b 8k rpool/swap

Внимательно смотрим на размеры блока - для SPARC он должен быть равен 8k, для x86 - 4k. Размер области подкачки примем равным (в нашем случае) двум объемам физической памяти. Так надо.

Осталось последнее - подключить swap к системе:

# swap -a /dev/zvol/dsk/rpool/swap

и сделать запись (если ее вдруг не окажется там) в /etc/vfstab:

/dev/zvol/dsk/rpool/swap - - swap - no -


Данную запись нужно поставить раньше, чем запись

swap - /tmp tmpfs - yes -

Это обеспечит нам автоматическое монтирование датасета подкачки при перезагрузке.

Вуаля - у нас подключена подкачка и dump-устройство. Можно выполнить zfs list и убедиться, что новые датасеты стали частью системы, а swap -l показывает активное устройство подкачки.

PS. Насколько быстро работает подкачка на датасете ZFS? Говорят, быстро. До сих пор мне не доводилось видеть начинающуюся подкачку на системах с ZFS. Системы на ZFS, по моим наблюдениям, вообще в принципе становятся более стрессоустойчивыми.

четверг, 21 мая 2009 г.

По следам киборга-убийцы


Кажется, я уловил закономерность появления этих патчей.

Выяснилось все после того, как я обновил одну из продуктивных систем (на самом деле это первое обновление с этим релизом) на Солярис 5/09.

Первая же команда после обновления:

# uname -a

показала (кто бы мог подумать) релиз ядра 139556-08.

Знаете, что это означает, мальчики и девочки?

Это означает, что патч для 10/08 с номерами 139555/139556-08 фактически является ядром другого релиза.

Фактически он есть то, что в iD Software называют point-release. Переходное обновление, фактически меняющее версию системы на следующую.

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

Сходится и по времени, они появляются прямо перед анонсом нового релиза, где-то за месяц.

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

Потому и нужно его ставить в честном single-user, да сделав предварительный физический бэкап.

У меня только один вопрос в Sun Microsystems.

Ребята, а предупредить о выходе нового релиза своих зарегистрированных пользователей почтовой рассылочкой, с указанием номера патча пойнт-релизного, которого надо опасаться и ставить либо через Live Upgrade, либо через бэкап - очень трудно?

Может быть, для вас является новостью трудность установки ядер новых релизов в старые?

А может, трудно хотя бы в patch readme написать - "Дорогие юзеры, этот патч - пойтн-релиз сделующего релиза, уважайте его до опасания и не разглашайте номер нового ядра до выхода официального релиза, пожалуйста!"?

Я открыл Америку?

Не думаю.

Я лишь думаю, что пока гром не грянет - Джон тоже не перекрестится.

Пока какой-нибудь value-added клиент и собутыльник Джонатана не угробит подобным патчем свою "весьма дорогую системочку" и не придет, потрясая судебным иском, требовать возмещения ущерба у саппорта (где сидят такие же, в телогреечке - "Ну до смерти же не убил? А у меня вот получилось оживить после патча! Так что не щитова!") - даже предупредить в readme никто не предупредит.

Хотя какая малость - было бы в readme написано предупреждение - саппорт мог бы с чистой совестью махнуть им перед моим носом - "Не прочитал перед установкой? Сам дурак, так тебе и надо, что систему ухлопал!"

Короче, мальчики и девочки. Будьте особенно бдительны, когда Козерог в Тельце - накануне выхода нового релиза Соляриса.

Загодя приготовьте boot environments для Live Upgrade, освежите flash-архивы, приготовьте стартовые и инсталляционные USB-устройства...

PS. Хорошая новость, мальчики и девочки. Выполнять Live Upgrade системы с ZFS root-pool не просто - а очень просто. Гораздо проще, чем сделать миграцию UFS->ZFS на руте. И дополнительных дисков уже не нужно. Тс-с-с!

среда, 13 мая 2009 г.

Патч 139556-08 - киборг-убийца

"Иногда они возвращаются".

Активно действующие SA знают, что Сан с некоторой степенью периодичности (раз в год-полтора) выпускает ядерные (kernel) патчи-дизастеры, выносящие продуктивные машины на Великий Небесный Сервер.

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

Но 139556-08 (и его брат-близнец 139555-08) - это леденящий душу термоядерный вырвиглазный Толстый Полярный Лис.

Забегая вперед, скажу сразу - патч гарантировано убивает системы, стоящие на ZFS. Имеются в виду системы с корневым пулом ZFS.

Никакие разумные меры предосторожности, описанные в patch readme, не помогают. Писец окончательный и бесповоротный, лишь физический бэкап спасет гигантов мысли.

Лис подстерегает всякого, кто ставит на подобные системы патчи в автоматическом режиме, скажем, с использованием pca.

Вы можете сказать "Я не ставлю патчи и мне ничего не грозит", и, возможно, будете даже слегка правы. Однако данный патч относится к разряду critical и security, и, если, скажем, у меня система стоит в злом Интернете, то не патчить ее обойдется мне лично чрезвычайно дорого. Начнем с того, что Nessus отсутствие данного патча определяет практически с момента его выхода, квалифицируя это как серьезную уязвимость. Если вдумчиво почитать описание патча, станет ясно, что песец-то, в общем и без его установки подстерегает. Так что "А придется! - сказала бабка, снимая с плеча ружье".

Однако все по порядку. Намедни у меня погибла одна продуктивная и одна девелоперская система (x86 и x64 соответственно) в результате установки данного патча. Обе системы роднит одно свойство - они обе стояли на полных зеркалах ZFS, обе регулярно обновляются посредством cron и pca на автопилоте.

При этом за пару дней до этого совершенно беспроблемно прошло обновление системы x64, стоящей на ufs (продуктивный сервер, который я предпочел оставить на ufs по причинам графика работы - 24x7x365 и высокой критичности - только это и спасло его от неминуемой гибели, как оказалось в дальнейшем).

Первые признаки не предвещали ничего страшного.

pca благополучно стартовал, выругивался на якобы отсутствующие и жизненно необходимые депенденты для данного патча - SUNWauda (ну очень нужная вещь на сервере, не так ли?), SUNWdoc, SUNWnisu, и SUNWgrubS (исходники GRUB, которые не ставятся по умолчанию в Entire Distribution и по закону подлости находятся на CD 5), затем patchadd делал попытку откатить пачт и собственно патч ложился архивом в каталог, в котором находился pca на момент запуска.

Все остальные патчи накатывались, включая пререквизиты для патча 139556-08, а затем начиналось самое интересное.

Система иногда хотела реконфигурационного ребута и после него вы вылетали в черную консоль с сообщением об отсутствии platform/i86pc/unix или platform/amd64/unix(это уже клиника, принимайте покойницу) либо сыпала жуткой руганью о невозможности загрузки большинства модулей и запуска краеугольного сервиса filesystem/minimal, без которого, разумеется, не стартует ни одна служба кроме шелла.

Все. На этом смерть. Системы не реанимировалась никак. Двое суток реанимационных процедур не привели ни к какому результату.

Что показало вскрытие?

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

Сам патч из-за неправильного ремаунта ZFS не полностью ставится и некорректно откатывается. В нем самом ошибка, приводящая к разрушению метаданных ZFS (с высокой вероятностью), а наиболее вероятным претендентом на второй баг является пререквизитный патч 140796-01 (согласно описанию, наиболее вероятная проблема в том, что кто-то физически забыл, что ZFS тоже нужен mount/umount.

Проверено на кошечках - во всех мыслимых вариантах установки, включая честнейший single user (reboot -- -s) после реконфигурационного перезапуска zfs рассыпается вдребезги. Импорты пострадавших пулов дают лишь обломки и три директории верхнего уровня. Работает лишь загрузчик. Никаким образом привести систему без бэкапа в божеский вид
нельзя.

Еще раз - системы, имеющие / на ufs - обновляются со свистом. Либо полный ufs, либо предварительное (со страху) демонтирование не-корневых пулов ZFS - и все проходит на ура. Протестировано на четырех машинах.

Вариант-альтернатива - конверсия посредством LiveUpgrade zfsBE в ufsBE, обновление, обратная конверсия в zfs root pool - как описано здесь и здесь.

Если нет другого диска - соболезнования, придется пройти через процедуру восстановления.

Если нет бэкапа - соболезнования, Песец.

Жизнь после смерти - что делать дальше?

Во втором случае обход был очевиден. Рядом с девелоперской машиной случился JumpStart-сервер. Быстрая установка системы на ufs (пришлось поменять профиль установки), обновление, конвертация Live Upgrade в zfs, зеркалирование, все. Реконструкция завершена.

В первом случае - продуктивная машина - спасло наличие flash-архивов. Создаваемых на регулярной основе посредством вот этого.

Однако все оказалось не настолько просто.

Восстановление с flash-архивов, хоть и быстрое (даже с NFS), в текущем релизе не выполняется на zfs - впрочем, это было лишь на руку.

Последовательность действий оказалась следующая.

1. Восстановление с flash-архива на ufs (на один диск из двух зеркальных).

Замечание: Учтите тот факт, что при восстановлении с flar некоторые данные из /etc не будут восстановлены. В частности, resolv.conf надо будет создавать заново. Все сервисы, минимизированные на момент записи архива, окажутся включенными и запущенными (что в моем случае привело к конфликту портов ssh и OpenSSH). Все остальное в основном восстановилось, по крайней мере, явных недостатков восстановления больше обнаружено не было.

2. Обновление системы на ufs (все еще на одном диске) с накатом киборга-убийцы. Накат выполняется в multi-user, посредством pca, и на грозные ноты в readme можно просто забить. Проблем на ufs нет.

3. Дальше самое интересное. Нам ведь хочется вернуть конфигурацию как было, на зеркалированный root-пул zfs.

Как мы это делаем? Последовательность действий не сработала, и вот почему. После восстановления у LU оказалось достаточно данных, говорящих, что "Я уже и стою на zfsBE".

Соответственно, попытка в лоб повторить действия по миграции с ZFS на UFS обломалась.

Вскрытие показало, что для воспроизведения процедуры 1 и процедуры 2 с чистого листа необходимо тупо удалить файл /etc/lutab и директорию /boot/grub/bootsign на восстановленном руте UFS.

Замечание: Сан запрещает редактирование (и, я так понимаю, любые другие действия над /etc/lutsb) lutab, однако, как и во многих других случаях подобных шаманских плясок в альтернативе лишь перестановка (шучу), а с другой стороны, команду cp никто пока не отменял. Делайте, иначе команды Live Upgrade будут обламываться. А попытки покопаться в /etc/lu не помогут.

После чего вышеописанные процедуры в точности позволили восстановить состояние системы на момент записи архива и на zfs - но уже пропатченой.

Вывод один. Хорошо, что такие устрашающие патчи выходят нечастно. Плохо - в ожидании такого дизастера нужно регулярно делать бэкапы. Хотя это кому как. Хорошая новость - flar можно записать в multi-user, он достаточно целостный для восстановления. Очень плохо - насколько можно судить по Гуглу, эту проблему на сегодня пока никто не обнаружил, включая техподдержку Сан.

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

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