Натолкнулся на проблему – иногда в киоске SunRay Server приложение “падает”, оставляя за собой core-файл, который потом успешно и безвозвратно теряется ввиду природы работы самих киосков – после падения критического приложения подчищается за собой все. Вариант один – внести модификацию в скрипты запуска киосков.
Вариант два – правильный 
Прописать создание core-файла в определнной заранее директории:
pfexec mkdir -p -m 0700 /var/core/uttsc-bin
pfexec coreadm -g /var/core/%f/%p-%t
pfexec coreadm -e global-setid
Старо как мир 
Подсмотрел здесь – http://forums.sun.com/thread.jspa?threadID=5396597
Еще один небольшой “плюсик” в копилку VirtualBox’a:
После “падения” операционной системы VirtualBox автоматически изготавливает снимок экрана последнего писка убитой мыши экрана гостевой ОС. Полезно для анализа падений, например, той же windows.
PS: в моем случае оказалось бесполезной вещью – я наткнулся, судя по всему, на баг VNICs don’t work inside OpenSolaris guests using bridged networking ( http://www.virtualbox.org/ticket/3925), плюс к этому гостевая OSol 2009.6 встала “колом” после моих игрушек с просто пустым черным экраном.
Все слышали про data corruption . Но – я уверен – никто толком не представляет – что это ТАКОЕ . Все орут – Я ПОТЕРЯЛ СВОЙ ФАЙЛ !!! ДАННЫЕ РАЗРУШЕНЫ !!! А как оценить – как часто такое происходит , что может случится с Вашими данными . И вот тут подвернулась статья – некотрые исследования из самого CERN’a – уж они-то могут говорить о данных буквально во вселенском масштабе – каждый из эксперимент порождает терабайты данных , которые нужно хранить , чтобы потом обрабатывать , чтобы потом опять хранить , обрабатывать , и так бесконечно долго – у них хранятся ПЕТАБАЙТЫ данных . И вот они-то и могут говорить об ошибках в системах хранения в глобальном масштабе . Читаем ! Здесь – http://storagemojo.com/2007/09/19/cerns-data-corruption-research/ . А началось все с какого-то data corruption во время проведения очередных работ Самое ценное ( imho ) , мне понравилось ( к вопросу – “что чаще все ломается?” ) :
* Disk errors.The wrote a special 2 GB file to more than 3,000 nodes every 2 hours and read it back checking for errors for 5 weeks. They found 500 errors on 100 nodes.
o Single bit errors. 10% of disk errors.
o Sector (512 bytes) sized errors. 10% of disk errors.
o 64 KB regions. 80% of disk errors. This one turned out to be a bug in WD disk firmware interacting with 3Ware controller cards which CERN fixed by updating the firmware in 3,000 drives.
* RAID errors. They ran the verify command on 492 RAID systems each week for 4 weeks. The disks are spec’d at a Bit Error Rate of 10^14 read/written. The good news is that the observed BER was only about a 3rd of the spec’d rate. The bad news is that in reading/writing 2.4 petabytes of data there were some 300 errors.
* Memory errors. Good news: only 3 double-bit errors in 3 months on 1300 nodes. Bad news: according to the spec there shouldn’t have been any. Only double bit errors can’t be corrected.
Казалось бы – при чем тут zfs
Всем мерси . Читайте внимательно .
