Показаны сообщения с ярлыком анализ. Показать все сообщения
Показаны сообщения с ярлыком анализ. Показать все сообщения

Цифровые фотокамеры Canon: характеристики и документация



6 коммент.
Те, кто занимается астрономией или оптикой, часто используют обычные зеркальные камеры. Параметрых этих камер - большая тайна, но кое-что раскопать всё-таки удаётся.
Спецификации, они же White Papers, есть правда разной степени сермяжности о том, что же засунул производитель в фотокамеру. Особенно волнует многих вопрос насчёт сенсоров и его характеристик. Относительно Canon огорчу: они делают сенсоры сами и делиться относительно параметров сенсоров, похоже, не намерены.

Тем не менее, кое-что можно найти в этих доступных материалах. Выкладываю ссылки на спецификации камер, которые мне удалось накопать при помощи всезнающего Гугла:

Огромное спасибо комментатору Павлу за дополнительные ссылки!

А вот это есть просто кладезь полезного и интересного: не жалейте мегабайтов трафика, друзья, ибо это есть подробное описание полнокадрового CMOS сенсора, который разработали ребята из Canon (Full Frame CMOS sensor). Там без кучи формул, на простом языке говорится, почему они перешли на CMOS и как отважно они решали свои проблемы.
Читать далее

Измерительные возможности цифровой камеры Canon 40D



6 коммент.
Этот пост будет интересен тем, кто использует цифровые фотокамеры в качестве измерительных. Чаще всего это физики, техники и астрономы. Здесь приведены фрагменты технического отчёта для одной из лабораторий МИФИ, которая дала нам на время 40D. Так что не ждите здесь дифирамбов Live-view и прочим потребительским штучкам. Нас она интересует как измерительное устройство.

Для выяснения правды был использован конвертер DCRAW, о чём уже писалось здесь. Для просмотра и анализа сырых данных из RAW-файла следует использовать графический анализатор nip2, о котором так же есть что почитать там и тут.



Как сделать из обычной камеры измерительную
Используем DCRAW с ключами:
dcraw -4 -D -T img0001.cr2

Ключ -4 имеет решающее значение: это позволяет выводить изображение в 16-битный формат, в котором содержится только 14 бит необработанных данных.

После этого данные можно загружать в MATLAB или Octave для работы или использовать nip2 для анализа данных.


Немного теории
Теоретический верхний предел значений пикселей фотокамеры равен разрядности АЦП - в данном случае это значение 16384 цифровых единиц. В современных цифровых камерах устанавливаются, как правило, 12-битные АЦП, однако в камерах высокой ценовой категории могут быть АЦП больших разрядностей (14 и 16 бит).

Несмотря на то, что значения, получаемые с фотосенсора, линейно зависят от времени экспозиции постоянного источника света, при подходе к теоретическому пределу значений отклик фотосенсора становится нелинейным. Значение насыщения меньше теоретического предела АЦП: например, для 12-битного АЦП, применяющегося в большинстве современных зеркальных камер, предел экспериментально получаемых значений меньше теоретического на 10-20%.


Для выяснения точки насыщения фотокамеры следует использовать стабильный световой источник и, возможно, ослабляющие оптические стёкла. В качестве осветителя хорошо подходят светодиодные фонари: стабильные по мощности, яркие и с широким спектральным составом. Объектив следует снять. После этого делаются экспозиции с равным шагом в RAW-формате.

После этого в системе численных математических расчётов MATLAB / Octave обрабатываются снимки по выделенной области интереса: анализируется ход среднего значения по области интереса и дисперсия значений в выбранной области. Это позволяет узнать, насколько линеен фотоприёмник камеры и при каких значениях освещённости начинается насыщение.

Как видно из хода зависимостей, на уровень насыщения, который равен значению 13826 из 16384, сенсор фотокамеры Canon D40 выходит плавно, и до уровня 12000-13000 зависимость от интенсивности зарегистрированной освещённости можно считать линейной с достаточно хорошей точностью (см.рис.1). В качестве погрешности отложено стандартное отклонение данных плоского поля размером 64х64 отсчёта.


a)



б)


Рис.1: Линейность фотосенсора в зависимости от сигнала:
а) на малых экспозициях (логарифмический масштаб),
б) на больших экспозициях (линейный масштаб).



Данные о шумах для камеры Canon 40D
Для этих целей следует использовать экспозицию с закрытой крышкой. Данные, полученные в ходе обработки таких данных, позволяют судить о росте уровня шума в зависимости от экспозиции и ISO. Следует отметить, что усиление сигнала (соответствующее значению ISO) происходит до записи изображения в RAW-файл. С возрастанием величины усиления возрастают и шумы.



a)


б)
Рис.2: Изменение статистических параметров темнового шума от величины ISO:
а)среднее значение,
б) стандартное отклонение от среднего значения



На рис.2 приведена зависимость среднего значения сигнала темнового кадра от ISO и стандартное отклонение этих значений при постоянном времени экспозиции. Видно, что стандартное отклонение возрастает с изломами (возможно, используется многоступенчатый АЦП).

На рис.3 представлены зависимости величины шума (стандартное отклонение пикселей при многократном усреднении одной и той же сцены для разных величин пикселей) от сигнала.


Рис.3: Зависимость сигнала от шума для данных, обработанных
DCRAW в документальном режиме.
Данные приведены для красного канала.



Рис.4: Зависимость сигнала от шума для данных,
обработанных DCRAW в документальном режиме.
Данные приведены для зелёного канала.



По нашим данным, при обработке получаемых изображений конвертером DCRAW, можно оценить полный динамический диапазон как 56 dB и линейный динамический диапазон как 52 dB.

Это очень хороший результат для бытовой камеры, т.к. аналогичное устройство класса "scientific graduated" стоит как минимум в 3-4 раза дороже. Так что Canon 40D можно вполне использовать в любительской астрономии и в качестве фоторегистратора в оптических экспериментах.

Читать далее

Создание графиков в gnuplot: пример построения графика



23 коммент.
Согласно официальной документации, gnuplot имеет интерактивный и поточный режим. В интерактивном режиме вы вводите команду за командой, задавая параметры строительства графика. Для изучения возможностей или чтобы построить единственный график это, наверное, нужно, но обычно проще написать скрипт и скармливать его гнуплоту. Об этом далее.

Как в gnuplot построить график
Gnuplot использует скриптовой язык, который описывает строительство графика функции или рядов данных. В скрипте задаются параметры графика: шрифты осей, пределы по осям, расположение легенды. После этого скрипт передаётся по конвейеру гнуплоту, и он выдаст файл PostScript, который и содержит график.

Чтобы быстро посмотреть и, при необходимости, перестроить график, нужно открыть его программой просмотра PS-файлов. Например, kghostview. Её вообще хорошо держать открытой на другом виртуальном рабочем столе, а скрипт построения графика изменять - и при перестраивании график в kghostview автоматически обновится.

Небольшой пример. Имеются ряды данных в обычном текстовом файле, нужно построить график. Вот исходные данные, файл RAWSTDmeasurementresult
1.6593991e+00 1.6523134e+00 1.6407763e+00
1.8986703e+00 1.8667678e+00 1.8595763e+00
2.6304331e+00 2.5340401e+00 2.4999678e+00
4.2843754e+00 4.0227936e+00 4.0423230e+00
7.6136102e+00 7.0438436e+00 7.1057056e+00

Нужно построить цветной график, с подписями на осях по-английски, шрифт Helvetica. Вот что у меня получилось:

#! /usr/bin/gnuplot -persist
set terminal postscript eps enhanced color solid
set output "~/matlab/programs/kmvdecoder/plots/1NoiseRAWSTDtoISOnoisecomparing.ps"
set xlabel "ISO number" font "Helvetica,18"
set bmargin 4
set ylabel "Pixels standard deviation" font "Helvetica,18"
set yrange [0:50]
set key top left
set xtics ("100" 0,"200" 1,"400" 2,"800" 3,"1600" 4)
set style line 1 lt 1 pt 9
set style line 2 lt 3 pt 7
set style line 3 lt 2 pt 5
plot "~/matlab/programs/kmvdecoder/plots/RAWSTDmeasurementresult" using 1 title "RAW data, Red channel" with linespoints linestyle 1,"~/matlab/programs/kmvdecoder/plots/RAWSTDmeasurementresult" using 2 title "RAW data, Green channel" with linespoints linestyle 3,"~/matlab/programs/kmvdecoder/plots/RAWSTDmeasurementresult" using 3 title "RAW data, Blue channel" with linespoints linestyle 2


Ничего сложного в этом нет, сейчас я эти иероглифы прокомментирую.

Даже беглый взгляд на текст при некотором знании английского позволяет догадаться, какие строчки что примерно делают. Понятно, что команда set что-то устанавливает - а устанавливает она параметры построения графика. А команда plot как нетрудно догадаться, что-то строит. Так что всего-то навсего две команды и немного параметров к ним. Не так страшно, как выясняется - для настоящего джигитапользователя никс-систем это не должно быть проблемой.


Пример скрипта построения графика на gnuplot с пояснениями
Итак, разбираем скрипт.

#! /usr/bin/gnuplot -persist
Это обычный заголовок скриптов, только указывает он на gnuplot а не на, скажем, perl или bash. Если вы когда-нибудь видели скрипты, то сразу почувствуете себя как дома.


set terminal postscript eps enhanced color solid
Устанавливает постскрипт-вывод, расширенный - можно использовать греческие символы, цветной - графики будут цветными.


set output "~/matlab/programs/kmvdecoder/plots/1NoiseRAWSTDtoISOnoisecomparing.ps"
Это путь к будущему графику и имя графика. Можно сваливать их в текущий каталог или куда захотите.


set xlabel "ISO number" font "Helvetica,18"
Подпись по оси Х будет "ISO number", шрифтом Helvetica и размером 18 пунктов.


set bmargin 4
Устанавливаем нижнее поле равное 4 относительным единицам, чтобы не обрезалась подпись к оси Х (этот досадный косяк имеет место быть у меня, у вас его может и не быть).


set ylabel "Pixels standard deviation" font "Helvetica,18"
Подпись по оси Y будет "Pixels standard deviation", шрифтом догадайтесь каким :-)



set yrange [0:50]
Пределы по оси Y составляют от 0 до 50.



set key top left
Легенда (обозначение рядов данных) сверху слева.



set xtics ("100" 0,"200" 1,"400" 2,"800" 3,"1600" 4)
Отсчёты по оси Х будут 100, 200, 400 800 и 1600.


set style line 1 lt 1 pt 9
set style line 2 lt 3 pt 7
set style line 3 lt 2 pt 5
Здесь задаётся номер линии (чтобы на неё сослаться при построении конкретного ряда данных), тип линии и тип точки (квадратик, кружочек, ромбик...).


plot "~/matlab/programs/kmvdecoder/plots/RAWSTDmeasurementresult" using
1 title "RAW data, Red channel" with linespoints linestyle
1,
"~/matlab/programs/kmvdecoder/plots/RAWSTDmeasurementresult" using 2
title "RAW data, Green channel" with linespoints linestyle
3,
"~/matlab/programs/kmvdecoder/plots/RAWSTDmeasurementresult" using 3
title "RAW data, Blue channel" with linespoints linestyle 2
Вся эта конструкция предписывает строить график, который будет состоять из трёх линий (типа 1, 2 и 3). График строится по данным, которые лежат в одном текстовом файле тут: ~/matlab/programs/kmvdecoder/plots/RAWSTDmeasurementresult

Заголовок у каждой ветви графика разный, он задаётся после
title, а слово using означает, что в файле несколько рядов данных: для первой ветви - первый столбик, для второй ветви - второй столбик и так далее.

Для каждой ветви графика задаётся свой стиль линии.
Вот, кстати, почему и зачем у меня появился в своё время пост о вертикальной конкатенации: мне нужно было добавить в файл данных ещё один ряд, полученный при других измерениях. После этого можно скармливать новый файл данных гнуплоту и он будет воспринимать это как новый ряд.
Ничего демонического, как видите, в гнуплоте нет. А вот и результат наших стараний:

Следует отметить, что, вопреки распространённому заблуждению, gnuplot выдаёт графики с publication-ready качеством, которые без вопросов принимаются в любом зарубежном (и уж тем более местном) научном журнале. Например, NASA с помощью gnuplot создаёт карты погоды, а некоторые математические системы (типа MATLAB) просто используют куски кода gnuplot чтобы отрисовывать графики. Так что график, который выдаст гнуплот, в любом случае на порядок краше того, на что способен ексель или Openoffice.org Calc.

Для тренировки можно немного поиграть с параметрами и посмотреть, к чему это приводит. Смотреть удобнее всего в kghostview или любой другой программе, способной открыть PostScript-файлы.
Читать далее

Отчего умирают винчестеры: небольшой обзор причин выхода из строя жёстких дисков



58 коммент.
Он есть у каждого из нас. Он - наше всё в прямом смысле слова, маленький кусочек высоких технологий и точной механики, на котором хранятся наши бесценные данные: фотографии, тексты, фильмы, музыка, конфиги и собственно операционная система. Это - Винчестер. Но рано или поздно, он выходит из строя - почему?

Предыстория вопроса
Всё началось с того, что я на работе решил скачать свежий Debian Testing и перенести его домой на мои большие винчестеры. Всё скачалось и записалось, выключил ноутбук в штатном режиме - в общем, всё, как всегда. Однако при копировании была выдана ошибка: I/O Error, и в логах dmesg засветилось:
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=35807470, high=2, low=2253038, sector=35807428
ide: failed opcode was: unknown
end_request: I/O error, dev hda, sector 35807428
Приехали - по диску пошли битые сектора. Дело плохо, и я решил посмотреть на данные SMART, чего, признаться, уже давно не делал.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000b 100 100 062 Pre-fail Always - 0
2 Throughput_Performance 0x0005 100 100 040 Pre-fail Offline - 0
3 Spin_Up_Time 0x0007 192 192 033 Pre-fail Always - 2
4 Start_Stop_Count 0x0012 099 099 000 Old_age Always - 1904
5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0
7 Seek_Error_Rate 0x000b 100 100 067 Pre-fail Always - 0
8 Seek_Time_Performance 0x0005 100 100 040 Pre-fail Offline - 0
9 Power_On_Hours 0x0012 085 085 000 Old_age Always - 6651
10 Spin_Retry_Count 0x0013 100 100 060 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 965
191 G-Sense_Error_Rate 0x000a 100 100 000 Old_age Always - 0
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 2
193 Load_Cycle_Count 0x0012 071 071 000 Old_age Always - 299688
194 Temperature_Celsius 0x0002 144 144 000 Old_age Always - 38 (Lifetime Min/Max 11/44)
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 5
197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 1

198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 0
А вот и герой торжества: сбойный сектор отловлен, и он уже не одинок - их там пятеро. Обидно перекачивать такой большой файл (хотя при подсчёте MD5SUM значение выдавалось правильное), но ещё обиднее терять данные - тут же была сделана резервная копия самых важных данных. Через день я выполнил на нём полное тестирование по SMART, и оно прошло гладко. Теперь сбойный сектор исчез (для меня, но не для SMART), и их теперь шестеро.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000b 099 099 062 Pre-fail Always - 0
2 Throughput_Performance 0x0005 100 100 040 Pre-fail Offline - 0
3 Spin_Up_Time 0x0007 204 204 033 Pre-fail Always - 2
4 Start_Stop_Count 0x0012 099 099 000 Old_age Always - 1906
5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0
7 Seek_Error_Rate 0x000b 100 100 067 Pre-fail Always - 0
8 Seek_Time_Performance 0x0005 100 100 040 Pre-fail Offline - 0
9 Power_On_Hours 0x0012 085 085 000 Old_age Always - 6659
10 Spin_Retry_Count 0x0013 100 100 060 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 966
191 G-Sense_Error_Rate 0x000a 100 100 000 Old_age Always - 0
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 2
193 Load_Cycle_Count 0x0012 071 071 000 Old_age Always - 299691
194 Temperature_Celsius 0x0002 171 171 000 Old_age Always - 32 (Lifetime Min/Max 11/44)
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 6
197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 0

198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 0
В общем, я уже понемногу откладываю деньги на новый винчестер, а пока решил выяснить, почему же они помирают.

Статьи, на которые я буду ссылаться, научные, так что не ищите там выкриков "самсунг\сигейт отстой\рулёз" и конкретных рекомендаций "покупайте у Васи - не прогадаете". Кто не знаком с жанром научной статьи, говорю сразу: это не рецепт, а скорее пища для дальнейших размышлений. Написано всё максимально дипломатично и завуалировано, но так, чтобы читатель уловил основные идеи, однако не ждите, что все результаты долгих исследований вам выложат на блюдечке с голубой каёмочкой. Это напоминает то, как одна хозяйка другой рассказывает рецепт своего фирменного блюда: вроде бы все ингредиенты упомянуты, но фирменный штрих, который и делает блюдо таким замечательным, скорее всего сказан не будет.

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


Причины, статистика, анализ
Итак, статья "Failure Trends in a Large Disk Drive Population" проливает немного света на причины выхода из строя винчестеров на серверах Гугл - авторы собирали данные в течении полутора лет (с декабря 2005 по август 2006) с почти 100.000 винчестеров, диски были SATA и ATA, 5400 и 7200 RPM, ёмкостью от 80 до 400Гб разных производителей.

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

Сообщается также, что вероятность гибели винчестера слабо связана с его степенью загруженности. Но если SMART сыплет ошибками типа scan errors, reallocation counts, offline reallocation counts, and probational counts - дело дрянь и пора делать бекапы :-)


Возраст
Вероятность отказа, как и следовало ожидать, растёт с возрастом диска, то есть с тем временем, которое он отработал. Диски, работающие до 1 года, чаще всего дохнут в первые три месяца. Резкий скачок вероятности выхода из строя - 2 года.


Производитель
В исследовании говорится, что, вопреки расхожему мнению, выход из строя жёсткого диска слабо зависит от того, кто произвёл этот диск, а больше зависит от конкретного экземпляра и в меньшей степени от того, в каких условиях он эксплуатируется. В доказательство они приводят тот факт, что данные по сбоям, регистрируемым SMART, почти не зависят от того, диски чьих производителей анализируются.


Нагрузки

Дальше они приводят данные по зависимости смертности дисков от степени их загруженности (т. е. от дисковых операций).



График из работы "Failure Trends in a Large Disk Drive Population", Eduardo Pinheiro, Wolf-Dietrich Weber and Luiz Andre Barroso, Google Inc., Appears in the Proceedings of the 5th USENIX Conference on File and Storage Technologies (FAST’07), February 2007

Оказывается, что только очень новые (до 3 месяцев) и очень старые (старше 3 лет) чаще всего дохнут от высоких нагрузок, в остальных возрастных категориях вероятность выхода из строя от нагрузок зависит слабо.


Температура
Считается, что температура - важнейший фактор для жёсткого диска и что лучше диски охлаждать. Здесь главное не дойти до маразма: температура винчестера ниже 15 градусов по Цельсию удваивает среднюю частоту выхода их из строя.



График из работы "Failure Trends in a Large Disk Drive Population", Eduardo Pinheiro, Wolf-Dietrich Weber and Luiz Andre Barroso, Google Inc., Appears in the Proceedings of the 5th USENIX Conference on File and Storage Technologies (FAST’07), February 2007

Гугловцы выяснили, что с повышением температуры винчестера риск отказа растёт медленно - хуже того, есть тенденция к тому, что дискам больше страшны низкие температуры. Интересно, что минимальный риск выхода из строя приходится на интервал температур от 36 до 45 градусов. Риск выхода из строя при температурах меньше 25 градусов почти вдвое больше, чем при 45, и возрастает быстро с уменьшением температуры.

Диски возраста до 2 лет чаще дохнут от холода (при температуре от 15 до 30 градусов), а старики (от 3 лет) мрут от перегрева (более 45 градусов).



Анализ данных SMART

Самые важные ошибки, на которые следует обращать внимание: Scan Error, Reallocation Count Offline reallocation Probational Count

Ошибка сканирования (Scan Error).
Электроника диска время от времени сканирует поверхность диска незаметно для пользователя и передаёт данные SMART - если будут найдены битые сектора, они, как правило, вскоре будут заменены на свободные. Однако гугловцы говорят: после первой же ошибки сканирования поверхности, вероятность выхода из строя винчестера в следующие 60 дней возрастает почти в 40 раз!


Количество перемещений (Reallocation Count).
Если при чтении информации возникают ошибки ввода-вывода и операционная система о них сообщает, такие ошибки перехватываются SMART и сбойный сектор заменяется нормальным из набора доступных. Количество перемещений отражает износ поверхности, однако это ещё не повод бить тревогу: около 90% гугловских винчестеров имеют отличное от нуля количество перемещений, хотя при этом годовая вероятность сбоя (
Annualized Fault Rate, AFR) повышается в 3-6 раз. После первого же перемещения сбойного участка, вероятность выхода из строя в следующие 60 дней увеличивается в 14 раз.


Остальные ошибки (в том числе Seek Error) не дают заметного вклада в общую статистическую картину дисковой смертности. Примечательно, что, например, выход диска из строя слабо соотносится с количеством циклов "старт-стоп". Однако если диску более 3 лет, следует его использовать непрерывно, так как частых включениях и выключениях вероятность выхода из строя повышается на 2%.

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

На десерт - самое вкусное: распределение вероятностей ошибок по данным SMART. На кладбище гугловых винчестеров винчестеры встречаются со следующим распределением сбоев:
Ошибки, которые SMART не отловила - 60%
Reallocation Count - около 40%
Seek Error - 30%
Offline Reallocation - 28%
Probe Count - 20%
Scan Error - 15%
CRC Error - менее 5%.
Ясно, что винчестеры дохнут не от одной ошибки, а чаще всего от нескольких, лидирует в которых сбойные сектора и ошибки позиционирования.
Следует отметить, что в винчестерах отдельных производителей Raw_Read_Error_Rate и Seek_Error_Rate параметры достигают максимума и обнуляютя несколько раз в день. Это связанно с политикой некоторых производителей в отношении SMART: в эти параметры пишутся все ошибки, а остальные производители только те, что не смог отловить контроллер.
За информацию спасибо s7ang3r


Время наработки на отказ
Другая статья, "Disk failures in the real world: What does an MTTF of 1,000,000 hours mean to you?", подробно разбирает, что такое MTTF, или mean time to failure. Статистика также очень впечатляющая (около 100.000 устройств).

Многие производители оценивают отказоустойчивость двумя связанными друг с другом оценками: ежегодная частота ошибок (Annualized failure rate, AFR) и среднее время отказа (mean time to failure). AFR оценивается на основе предсказаний по результатам ускоренных тестов, а MTTF оценивается как время работы за год делённой на AFR. Ведущие производители дисков заявляют, что MTTF их устройств - от 1 млн. часов до 1.5 млн. часов в соответствии с AFR равной 0.58% и 0.88% соответственно.
Для любознательных: делается это потому, что проверять диски непосредственно, включив их и оставив, скажем, на 4-5 лет, просто невозможно, потому как производителю данные о надёжности нужны сейчас, а не через 5 лет, когда эти диски безнадёжно устареют. Поэтому разработаны и проводятся так называемые ускоренные тесты, при которых устройства загоняют в заведомо невыносимые условия работы (страшная жара \ лютый мороз и катастрофические дисковые нагрузки) и смотрят, сколько они в таком режиме протянут. Ясное дело, что дохнут они там очень быстро - и эти данные потом экстраполируются (т.е. пересчитываются с предсказанием) на нормальные условия работы. Конечно, точность таких предсказаний не слишком высока, но это лучше, чем ничего.
Чаще всего исходные данные таких исследований строго охраняются компанией-производителем и не просачиваются за пределы лабораторий. На выходе цифры, полученные такими методами, несколько приукрашиваются отделом маркетинга, и мелкими буквами вписываются на сайте для тех, кто интересуется.
Искать правду в этой мутной воде - дело гиблое, и остаётся ориентироваться на научные исследования разной степени достоверности, отчёты о которых время от времени публикуются на научных конференциях.
В статье говорится о том, что их данные о частоте замены винчестеров ввиду сбоев, мягко говоря, расходятся с тем, что заявляет производитель. Так, в трёх дата-центрах, в которых снимались данные для этой статьи в течение 5 лет, в общем случае замены жёстких дисков в связи со сбоями были несколько чаще, чем замена планок оперативной памяти, в 2.5 раза чаще, чем замена процессоров, в 2 раза чаще, чем замена материнских плат. Факт остаётся фактом: сбои винчестеров - одни из самых распространённых причин остановки узлов дата-центров для замены оборудования.

Дальше в рамках исследования было вычислено значение ежегодной частоты ошибок (AFR) для всех датацентров, в которых это исследование проводилось, и вот график:


График взят из работы: Bianca Schroeder, Garth A. Gibson "Disk failures in the real world: What does an MTTF of 1,000,000 hours mean to you?", FAST ’07: 5th USENIX Conference on File and USENIX Association Storage Technologies.

Он стоит тысячи слов: горизонтальная сплошная прямая соответствует заявляемым 1.5 млн. часам безотказной работы, горизонтальная пунктирная - 1 млн. часов, а точечная - реальному усреднённому времени работы. Согласно этому, AFR составляет 3%, а соответствующее MTTF - около 300 тыс. часов.

Но и эта цифра несколько завышена: не секрет, что в дата-центрах сделано всё, чтобы оборудование работало дольше. Это и системы кондиционирования, и распределение вычислительной нагрузки, и защита от перегрева \ переохлаждения отдельных компонентов и проч. Едва ли в пользовательских машинах имеется нечто подобное, особенно это касается ноутбуков.

Разброс таких данных велик: AFR составляет от 0.5% до 13.6%, и это в дата-центрах. Последняя цифра соответствует примерно 7 годам работы винчестера, но понятно, что в бытовых устройствах эта цифра намного скромнее: постоянно меняющаяся температура устройства, небольшое время непрерывной работы, скачки напряжения, большое количество циклов "старт-стоп" и прочее сильно сокращают время жизни жёстких дисков.

Ещё один замечательный график, показывающий жизненный цикл жёстких дисков в зависимости от времени работы:

График из работы J. Yang and F.-B. Sun., "A comprehensive review of hard-disk drive reliability". In Proc. of the Annual Reliability and Maintainability Symposium, 1999.

Как остроумно назвали авторы работы такую форму графика, "bathtub curve", т.е. кривая в форме ванной :-)

Интересные выводы в работе такие:
  1. MTTF, которое заявляет производители, более чем в 3 раза превосходит тот, который оценен в реальных условиях дата-центров.
  2. Для старых винчестеров, отработавших 5-8 лет, переоценка MTTF производителями составляет более 30 раз.
  3. Даже для сравнительно новых жёстких дисков (менее 3 лет работы) MTTF производителем завышена по крайней мере в 6 раз.
  4. Частота замен для дорогостоящих SCSI-дисков и обычных SATA почти одинакова.
И далее по работе: Для дисков, чьё время непрерывной работы менее 5 лет, частота замены в связи со сбоями в 2-10 раз больше той, которая следует из времени MTTF, а для старше 8 лет эта частота замен в 30 раз больше.


Как просмотреть информацию SMART
Для этого уже должны быть установлен пакет smartmontools, который содержит в том числе утлиту smartctl. После этого:
  • для IDE-дисков пишем smartctl --all /dev/hda
  • для SCSI-дисков smartctl --all /dev/sda
  • для SATA-дисков smartctl --all -d ata /dev/sda
Будет выведена длинная таблица, в которой будет много интересного.

smartctl version 5.36 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Device Model: HTS421260H9AT00
Serial Number: HKA210AJGKHV1B
Firmware Version: HA2OA70G
User Capacity: 60.011.642.880 bytes
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: 7
ATA Standard is: ATA/ATAPI-7 T13 1532D revision 1
Local Time is: Fri Oct 19 17:12:58 2007 MSD
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Здесь, собственно, информация о винчестере - размер, серийный номер.



=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 645) seconds.
Offline data collection
capabilities: (0x5b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
No Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 47) minutes.

Здесь данные о том, какие тесты поддерживаются SMART в устройстве и сколько они по времени будут занимать.

А дальше идёт самое интересное.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000b 100 100 062 Pre-fail Always - 0
2 Throughput_Performance 0x0005 100 100 040 Pre-fail Offline - 0
3 Spin_Up_Time 0x0007 202 202 033 Pre-fail Always - 1
4 Start_Stop_Count 0x0012 099 099 000 Old_age Always - 1930
5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0
7 Seek_Error_Rate 0x000b 100 100 067 Pre-fail Always - 0
8 Seek_Time_Performance 0x0005 100 100 040 Pre-fail Offline - 0
9 Power_On_Hours 0x0012 085 085 000 Old_age Always - 6745
10 Spin_Retry_Count 0x0013 100 100 060 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 978
191 G-Sense_Error_Rate 0x000a 100 100 000 Old_age Always - 0
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 2
193 Load_Cycle_Count 0x0012 071 071 000 Old_age Always - 299731
194 Temperature_Celsius 0x0002 196 196 000 Old_age Always - 28 (Lifetime Min/Max 11/44)
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 6
197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 0

Выделенные красным строки - для повышенного внимания, полужирным - для внимания пристального. В общем, если данные в них ненулевые, то есть имеются определённые ошибки, это ещё не повод для вселенской катастрофы, просто сигнал к тому, что неплохо бы выяснить адресок ближайшего сервис-центра по обслуживанию ноутбука вашей фирмы и отложить немного денег на замену винчестера. Хорошо бы ещё сделать полный дамп данных, пока это ещё возможно (чтобы потом залить на новый винчестер сразу всё). Или по крайней мере сделать копию содержимого /etc и /home


Error 4 occurred at disk power-on lifetime: 6652 hours (277 days + 4 hours)
When the command that caused the error occurred, the device was active or idle.

After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 d6 ee 60 22 e2 Error: UNC 214 sectors at LBA = 0x022260ee = 35807470

Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
25 00 00 c4 60 22 e0 00 00:29:58.200 READ DMA EXT
25 00 00 c4 5f 22 e0 00 00:29:58.200 READ DMA EXT
25 00 00 c4 5e 22 e0 00 00:29:58.200 READ DMA EXT
25 00 00 c4 5d 22 e0 00 00:29:58.200 READ DMA EXT
25 00 00 c4 5c 22 e0 00 00:29:58.100 READ DMA EXT

Далее пойдёт описание ошибок, если таковые случались. У меня это была ошибка ввода-вывода.

Ниже будут следовать данные о том, какие тесты запускались и чем они окончились. Если они завершились с ошибками - это верный признак скорой кончины винчестера.

SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed without error 00% 6651 -
# 2 Short offline Completed without error 00% 6651 -
# 3 Short offline Completed without error 00% 3097 -
# 4 Short offline Completed without error 00% 806 -

Надеюсь, что эта статья поможет выяснить причину, почему сломался жёсткий диск.


Ссылки
Для дальнейшего изучения параметров SMART можно обратиться к этой ссылке, здесь говорят о SMART в целом. Эта статья также многое поможет прояснить.
Читать далее

Продвинутые средства анализа изображений в nip2



7 коммент.
Некоторое время назад я уже писал об этом замечательном графическом редакторе nip2 для огромных изображений - сейчас я хочу записать методы обработки изображений в нём. По роду текущей деятельности приходится иметь дело с 12-битными изображениями (конвертированные RAW-файлы при помощи dcraw в полностью документальный режим), так что просматривать и работать с такими картинками в обычных редакторах (типа GiMP или Krita) не удобно. Зато в nip2 можно и просматривать изображения любой битности, и выполнять весьма изощрённые методы обработки. Об этом ниже и будет говориться.


Несколько слов об интерфейсе
Способ взаимодействия с пользователем у nip2 весьма оригинален, и к нему требуется привыкнуть. Это своеобразная таблица, каждая следующая ячейка которой - результат операции с предыдущей. И так далее: таким образом, конечный результат зависит от результатов обработки на предыдущих шагах, и при изменении любого шага автоматически пересчитывается.
Это одна из изюминок nip2. Например, вы создали некую последовательность фильтров, откадрировали и хотите быстро посмотреть фурье-спектр, но для другого изображения вместо загруженного сейчас. Легко и просто: щёлкаем правой кнопкой мыши по ячейке с исходным изображением (как правило, левое верхнее), и выбираем "Replace from file".
После этого результаты всей цепочки фильтров и преобразований быстро пересчитаются для нового изображения. Это бывает очень полезно при анализе результатов экспериментов.

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


Изменение масштаба яркости при просмотре
Очень полезная функция для просмотра изображений.

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


Быстрое масштабирование
Для того, чтобы изменить масштаб, совсем не обязательно искать на панели инструментов какую-то кнопку: достаточно, удерживая клавишу CTRL на клавиатуре, покрутить колёсиком мыши - и изображение в окне будет менять свой масштаб. Естественно, на оригинальном файле это не отразится.


Быстрое выделение области
Если нужно быстро выделить область интереса на изображении, достаточно зажать клавишу CTRL на клавиатуре и начать выделять мышью нужную область. Тут же будет создана новая область с названием, соответствующем текущему ряду и последнему свободному номеру ячейки (например, если ряд B и ячейка 14 последняя - новая будет называться B15).


Быстрое перемещение по изображению
Колёса продолжают рулить! Колесом мыши можно скроллить изображение вверх-вниз, а если зажать SHIFT и использовать колесо мыши - скроллинг будет в направлениях "влево-вправо". Очень удобно перемещаться так без использования полос прокрутки.


Горячие клавиши в nip2
Если вы часто используете какую-то функцию, есть смысл поставить на неё горячую клавишу. Для этого открываем меню, доходим до нужной нам функции кнопками клавиатуры, подсвечиваем её (или нажимаем её кнопкой мыши и держим для подсветки) и наживаем к примеру сочетание клавиш CTRL+M - и теперь эту функцию можно вызвать по нажатию CTRL+M.



Анализ изображений в nip2

С помощью nip2 можно проводить довольно сложный анализ изображений: Фурье-анализ, корреляционный анализ, свёртка, low-pass/high-pass фильтры и прочее.

Фурье-анализ в nip2
Часто бывает необходимо видеть Фурье-спектр изображения, особенно тогда, когда к нему применяются методы обработки. Для этого идём в Toolkits - Math - Fourier - Forward для прямого фурье-преобразования. Считается оно в первый раз довольно долго, зато потом будет пересчитываться быстро.

Там же, в nip2, можно выполнить и обратное фурье-преобразование. Для этого идём в Toolkits - Math - Fourier - Reverse и получаем назад своё изображение.

Гистограмма изображения в nip2
Гистограмма это зависимость количества пикселей одного уровня яркости от яркости изображения - она даёт представление о том, пикселей какой яркости на изображении больше или меньше. Функция чрезвычайно полезная при анализе изображений, и, разумеется, она присутствует в nip2. Для этого выделяем изображение, которое собираемся анализировать, и идём в меню Toolkits - Histogram - Find - One Dimension.
В результате, как на скриншоте выше, имеем красивую и информативную гистограмму изображения.



Изменение изображений в nip2
Некоторые привычные операции, такие как кадрирование, в nip2 есть, просто они могут выглядеть, согласно философии nip2, несколько непривычно...

Кадрирование
Есть и эта операция, причём её можно делать и визуально, и имея точные координаты.
Точное кадрирование можно осуществить, либо когда вам известны координаты области, либо используя nip2 в поточном режиме (для этого следует использовать команду vips и мануал к ней). Отмечаем ячейку с изображением, которое необходимо кадрировать, и идём в Toolkits - Image - Crop. После этого появится ещё одна ячейка ниже, и
потребуется указать координаты среза.

Визуальное кадрирование можно применить к изображению, открыв изображение на просмотр в окне, идём в меню File - New - New Region. Теперь меняем размер области и её положение по вкусу.
А можно сделать и ещё проще: для кадрирования в nip2 достаточно, зажав клавишу CTRL, выделить желаемую область на изображении - и в следующей ячейке сразу же появится желаемая область выделения.


Порог
Казалось бы, простая вещь - есть в любом уважающем себя графическом редакторе. В nip2 это тоже есть, но не так очевидно. Мне пришлось некоторое время поломать голову и проявить немного сообразительности: порог, как выясняется, можно сделать в два этапа. В nip2 есть простые статистические операции: среднее, минимум, максимум и прочее. Выделяем изображение и находим, например, среднее (Toolkits - Math - Statistics - Mean). В следующей ячейке появится число:
Теперь выделяем, зажав Shift, сначала ячейку с числом, а потом ячейку с картинкой. После чего идём в математику (Toolkits - Math) и ищем Relational (Соотношения). Выбираем Less than - это ли не порог? Отлично, в следующей ячейке появится чёрно-белое изображение с порогом. На скриншоте выделено полупрозрачным.
Обновлено: оказывается, всё проще - в nip2 недавно появилась специальная функция порога, которая упрятана в меню Toolkits - Image - Select - Threshold.

Склеивание изображений в nip2.
Чтобы склеить несколько изображений в одно, вовсе не нужен фотошоп - с этим прекрасно и быстро справляется nip2. Причём справляется тем лучше, чем больше изображений или фотографий нужно склеить. Например, если у вас имеются снимки со сканирующего микроскопа и нужно склеить десяток снимков - это лучше сделать в nip2. Для этого идём в меню Toolkits - Image - Join - Left to Right если хотим склеить изображения по горизонтали (левый край к правому краю) или Top to Bottom (если нужно склеить верхний край изображения к нижнему краю). Вот что при этом получается:


Пользуясь Toolbox - Image - Join, легко склеить несколько больших изображений в одно для последующего просмотра и анализа.


Корректировка перекоса яркости (tilt brightness)
Следует отметить, что при научных съёмках часто на изображениях появляется перекос яркости: когда одна часть изображения освещения сильнее другой (меняющаяся яркость от края изображения к середине). Этот достаточно неприятный эффект можно устранить в nip2 так: Tools - Filters - Tilt brightness.
Это позволит восстановить освещённость на изображении. А используя табличное свойство nip2, вы получаете возможность оперативно перерисовать большое изображение с учётом скорректированной яркости.

Вывод посчитанных данных
Вывод посчитанных значений из nip2 делается так: открываем меню View / Workspace Definitions, и пишем:
main = A1;
нажимаем "Process". После этого сохраняем Now save the workspace as "test.ws" and at the
command-line run:
$ nip2 -bp test.ws
и получите свои данные в консоли.

Резюме
Здесь я привёл несколько наиболее часто используемых мной возможностей nip2 для просмотра и анализа изображений. На всякий случай, особенности сборки последних версий nip2 в Linux описаны в этом посте.

Читать далее

Лог-файлы в Linux: зачем они нужны и как их достать



10 коммент.
Так как это постоянный вопрос новых пользователей на Линукс-форумах, им посвящается этот пост.

Новичку на форуме Линукс.
// читается скороговоркой//

Помогите телепатам!
Сообщите про железо,
Расскажите о системе,
Не скрывая ничего.

В этом деле благородном
Да поможет вам дэмэседж*
Вместе с эльэсписиаем**
Не забудьте про унэйм***

Не скрывайте ваши логи,
И конфиги, кстати, тоже,
А запостите на форум
Со скриншотами на пару.

И тогда уж стопудово
Аксакалы юниксвея
Вам помогут и подскажут,
Как систему починить.

----------------------
* имеется в виду dmesg
** вывод команды lspci
*** команда uname -a



Зачем нужны лог-файлы и почему они важны

Нормальные [?] операционные системы ведут подробный протокол собственных действий, записывая всё происходящее в текстовые файлы, log-файлы, лог-файлы или логи. Это обычные текстовые файлы, которые можно прочесть любым текстовым редактором (или средствами самой операционной системы), хотя многие логи доступны на чтение только пользователю root.
Главное: по логам можно восстановить почти полную картину неполадки, попутно выяснив особенности вашего железа и степени его поддержки.

Вот как выглядят лог-файлы в Linux:
usbcore: registered new interface driver hiddev
input: Logitech USB Receiver as /class/input/input1
input: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:00:1d.0-1
input: Logitech USB Receiver as /class/input/input2
input,hiddev96: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:1d.0-1
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
usb 1-5: new high speed USB device using ehci_hcd and address 3
usb 1-5: configuration #1 chosen from 1 choice
scsi0 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 3
usb-storage: waiting for device to settle before scanning
scsi 0:0:0:0: Direct-Access ChipsBnk SD/MMCReader 4081 PQ: 0 ANSI: 2
sd 0:0:0:0: [sda] 499712 512-byte hardware sectors (256 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 0b 00 00 08
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] 499712 512-byte hardware sectors (256 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 0b 00 00 08
sd 0:0:0:0: [sda] Assuming drive cache: write through
sda: sda1 sda2
sd 0:0:0:0: [sda] Attached SCSI removable disk
sd 0:0:0:0: Attached scsi generic sg0 type 0
usb-storage: device scan complete
Из этого куска лога видно, что произошло два события:
  • подключилась мышь (выделено фиолетовым): input: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:00:1d.0-1 и скорее всего эта мышь беспроводная (об этом говорит USB Receiver)
  • подключили USB-накопитель (выделено зелёным): usb 1-5: new high speed USB device using ehci_hcd and address 3, который опознан как USB-диск scsi0 : SCSI emulation for USB Mass Storage devices ёмкостью 256Мб sd 0:0:0:0: [sda] 499712 512-byte hardware sectors (256 MB) и содержащий две партиции (два раздела с данными) sda: sda1 sda2.
Как видите, из лог-файлов можно выудить огромное количество подробностей о работе аппаратуры. Другие лог-файлы могут содержать сообщения об ошибках и часто рецепты, что можно попробовать для их исправления.

Где хранятся лог-файлы в Linux

Все лог-файлы должны лежать в одном каталоге, который находится тут:
/var/log/
В общем, довольно логично. Но заходить туда не обязательно: вспоминаем, что консоль - наш друг и мощное оружие в умелых руках. Для того, чтобы быстро получить логи и прикрепить их к посланию на форум / опубликованию / пересылке по почте делаем так:
  1. Из консоли:
    1. в графическом режиме - в меню программ она может называться xterm, terminal, konsole, bash.
    2. в консольном режиме - если видите перед собой чёрный экран со словами типа penta4@penta4rce:~$ ничего пока делать не надо - вы и так в консоли :-)
  2. Далее пишем:
    1. dmesg > dmesg.txt
    2. lspci -v > lspci.txt
    3. cp /var/log/X.org.0.log ~/
  3. Далее видим в своём домашнем каталоге файлы dmesg.txt и lspci.txt и X.org.0.log
Вот этих файлов от вас так настойчиво добиваются на форумах. Наличие логов, вместе с подробным описанием проблемы и разумным количеством скриншотов способны радикально быстрее получить грамотный и исчерпывающий ответ (а ещё чаще - прямую ссылку на решение).

Для более подробного изучения неполадки и выяснения особенностей работы аппаратуры можно использовать приёмы работы, замечательно описанные здесь.
Читать далее

Глубокий анализ данных, Эпизод 3: повреждённые разделы



7 коммент.
Проблема: флеш-накопитель или винчестер не монтируются, в логах соообщения о повреждении таблицы разделов - что делать?
Решение: программа Testdisk может серьёзно помочь в деле восстановления убитых разделов в Линукс.

Ситуация
Мне нужно было перепрошить DVD-привод, о чём я уже писал ранее. После того, как всё удачно завершилось, мне нужно было перезагрузиться. Конечно, всё было выполнено в штатном режиме: shutdown -r now и всё шло нормально. Однако после перезагрузки мой 400Гб винчестер, который обычно висит на /dev/sdc1, монтироваться отказался наотрез. Я пошёл искать правды в логах dmesg:

Jan 7 17:46:08 localhost kernel: scsi1 : ata_piix
Jan 7 17:46:08 localhost kernel: Vendor: ATA Model: WDC WD360GD-00FL Rev: 31.0
Jan 7 17:46:08 localhost kernel: Type: Direct-Access ANSI SCSI revision: 05
Jan 7 17:46:08 localhost kernel: Vendor: ATA Model: WDC WD2500JD-00H Rev: 08.0
Jan 7 17:46:08 localhost kernel: Type: Direct-Access ANSI SCSI revision: 05
Jan 7 17:46:08 localhost kernel: Vendor: ATA Model: WDC WD4000KS-00M Rev: 07.0
Jan 7 17:46:08 localhost kernel: Type: Direct-Access ANSI SCSI revision: 05

винчестер ядро видит, и даже верно определяет его объём - значит, это не шлейф отошёл, и всё гораздо хуже. А вот и проблема:

Jan 7 17:46:08 localhost kernel: SCSI device sdc: 781422768 512-byte hdwr sectors (400088 MB)
Jan 7 17:46:08 localhost kernel: SCSI device sdc: drive cache: write back
Jan 7 17:46:08 localhost kernel: SCSI device sdc: 781422768 512-byte hdwr sectors (400088 MB)
Jan 7 17:46:08 localhost kernel: SCSI device sdc: drive cache: write back
Jan 7 17:46:08 localhost kernel: sdc: unknown partition table

Всё, приехали - на винчестере нет разделов! Три месяца работал прекрасно, а тут такое... Попытка примонтировать любыми правдами и неправдами /dev/sdc приводила к матюганию:
EXT3-fs error (device sdc): ext3_check_descriptors: Block bitmap for group 880 not in group (block 0)!
EXT3-fs: group descriptors corrupted !
Да, не весело. Сокраментальный вопрос: что делать!?

Поиск ответа на извечный вопрос
Немного погуглив на эту тему, я нашёл длинный тред на lkml и на дебиановском форуме, где было много стенаний по этому поводу - в том числе много отрицательных результатов при применении e2fsck. После этого данные оказывались угробленными окончательно. И тут я вспомнил, что давно хотел попробовать утилиту Testdisk, которая имеется в Дебиан - вот, думаю, кстати и попробую, благо ничего имитировать не надо, всё и так уже порушено...

Восстанавливаем разделы с помощью testdisk
Собственно, apt-get install testdisk был проделан давно, и от рута запускаем:
# testdisk
Программа работает в интерактивном режиме, выводя все партиции. Так что будьте предельно осторожны! Будут выведены все подключённые дисковые накопители:

Дальше скриншотов я не делал - не до того было. Но интерфейс у testdisk прост - даже тогда, когда вы немного волнуетесь по поводу сохранности полтерабайта ваших данных :-)
Так, заходим дальше, на устройство с повреждённой партицией. Программа напишет, что повреждение имеет место быть и предложит проанализировать таблицу разделов. Естественно, соглашаемся. Работать testdisk будет пропорционально объёму винчестера: будет произведён поиск резервных копий информации о структуре данных. Если вам повезёт, то копии будут найдены и будет предложено записать на диск изменения. Записываем. После этого предлагается перезагрузиться, чтобы изменения вступили в силу (забытое действие, которое реализуется shutdown -r now :-))

После этого система загрузилась и подмонтировала диск, как будто ничего и не было. Даже никаких сообщений типа "transactions replayed". Данные в полном порядке - в общем, как будто ничего и не было.

Заключение
В общем, всё хорошо, что хорошо кончается. Теперь, конечно, при перезагрузке я буду вручную отмонтировать оба жёстких диска (благо это происходит не чаще, чем через пять-шесть месяцев). По поводу происшедшего на форумах были мысли, что это init-скрипты в ряде дистрибутивов написаны так, что не учитывают очерёдность отмонтирования. Надо будет проверить - следующий раз может быть не таким удачным...
В качестве пособия был использован этот сайт и любимец всех линуксоидов - Gooooogle :-)
Читать далее

Глубокий анализ данных, Эпизод 2: The Sleuth Kit



6 коммент.
Продолжая тему о программах анализа данных, в этом посте пойдёт речь о семействе утилит судебного анализа (forensic analys) The Sleuth Kit. В дистрибутив Debian оно пока не входит (в Sarge v3.1r1 во всяком случае), но это не мешает скачать сырцы с сайта проекта и собрать самостоятельно.

Установка
Для того, чтобы начать использовать The Sleuth Kit, требуется распаковать тарбол в любую директорию и просто набрать в ней make. Для сборки программы нужны библиотеки SSL, которые нужно предварительно поставить, как и говорилось в файле README. В дистрибутив они входят:
# apt-cache search libssl
libssl-dev - SSL development libraries, header files and documentation
libssl0.9.6 - SSL shared libraries (old version)
libssl0.9.7 - SSL shared libraries
dcmtk - The OFFIS DICOM toolkit command line utilities
libdcmtk0 - The OFFIS DICOM toolkit runtime libraries
libdcmtk0-dev - The OFFIS DICOM toolkit development libraries and headers
Так что это потребует около 7Мб дискового пространства. Если нам его не жалко, ставим:
# apt-get install libssl0.9.7 libssl-dev
После того, как всё настроится и установится, можно приступать к сборке:
# make
В результате должно всё собраться, а утилиты появятся в подкаталоге ../bin, который до сборки был пуст. После сборки там появится много утилит, часть которых будет описываться далее.

Если у вас библиотки ssl не установлены, при компиляции вы получите ошибку такого вида:
checking for initscr in -lncurses... yes
checking for uncompress in -lz... yes
checking for ssl3_new in -lssl... no
configure: error: OpenSSL developer library 'libssl' not installed; cannot continue.
make[1]: Entering directory `/home/penta4/temp/1/src/afflib/lib'
make[1]: *** Не заданы цели и не найден make-файл. Останов.
make[1]: Leaving directory `/home/penta4/temp/1/src/afflib/lib'
Error: Missing lib/libafflib.a file
make: *** [no-perl] Ошибка 1

Это значит, что упомянутые выше библиотеки у вас не установлены и вам их нужно поставить.

Ищем и находим данные

После установки в вашем распоряжении окажется почти три десятка утилит, способных дать исчерпывающую информацию и том, что и как записано на носителе. Разумеется, утилиты прекрасно работают с raw-данными, полученными dd или recoverdm, о которой уже было написано.
Следует отметить, что если программа foremost предназначена скорее для экспресс-анализа и представляет собой утилиту вида "всё в одном флаконе", то The Sleuth Kit это набор утилит для более глубокого исследования данных. Но это лучше показать на примере, в котором используется версия 2.07.

Пример
Пусть имеется образ флешки в файле 1.img, и на ней есть данные, которые нужно извлечь без монтирования. Для этого сначала смотрим, какие структуры данных вообше присутствуют на диске - это делает утилита mmls - media management lister. Она показывает разметку диски, в том числе пустые области (unallocated spaces), а так же адреса начала и окончания партиций.
Поддерживаются следующие типы партиций:
dos (DOS-based partitions [Windows, Linux, etc.])
mac (MAC partitions)
bsd (BSD Disklabels [FreeBSD, OpenBSD, NetBSD])
sun (Sun Volume Table of Contents (Solaris))
gpt (GUID Partition Table (EFI))
Так, применяем mmls для того, чтобы узнать, какое расположение и тип партиций:
$ mmls 1.img
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

Slot Start End Length Description
00: ----- 0000000000 0000000000 0000000001 Primary Table (#0)
01: ----- 0000000001 0000000031 0000000031 Unallocated
02: 00:00 0000000032 0000031359 0000031328 DOS FAT12 (0x01)
03: ----- 0000031360 0000031487 0000000128 Unallocated
Всё верно, досовская файловая система на флешке (выделение полужирным - моё). Теперь известно, откуда она начинается и где заканчивается - эта информация нужна для работы других утилит.

Отлично, теперь мы знаем тип файловой системы и где она располагается. Посмотрим, как много данных на ней есть и что мы может оттуда выдрать - в этом деле нам поможет другая утилита, fsstat. Вызываем её, сообщая сведения, полученные от mmls:

penta4@penta4rce:~/temp$ fsstat -f fat -o 0000000032 1.img
FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: FAT12

OEM Name: +/J8LIHC
Volume ID: 0x913
Volume Label (Boot Sector): SANVOL
Volume Label (Root Directory):
File System Type Label: FAT12

Sectors before file system: 32

File System Layout (in sectors)
Total Range: 0 - 31327
* Reserved: 0 - 0
** Boot Sector: 0
* FAT 0: 1 - 12
* FAT 1: 13 - 24
* Data Area: 25 - 31327
** Root Directory: 25 - 56
** Cluster Area: 57 - 31320
** Non-clustered: 31321 - 31327

METADATA INFORMATION
--------------------------------------------
Range: 2 - 500226
Root Directory: 2

CONTENT INFORMATION
--------------------------------------------
Sector Size: 512
Cluster Size: 4096
Total Cluster Range: 2 - 3909

FAT CONTENTS (in sectors)
--------------------------------------------
57-64 (8) -> EOF
65-80 (16) -> EOF
81-88 (8) -> EOF
89-96 (8) -> EOF
97-408 (312) -> EOF
409-688 (280) -> EOF
689-696 (8) -> EOF
697-1000 (304) -> EOF

Отлично, теперь мы знаем, сколько файлов записано и где они расположены. Самое время посмотреть на структуру каталогов и файлов, начиная с корневого каталога. Для этого воспользуемся утилитой fls, которая показывает не только записанные, но и удалённые файлы. Посмотрим, что есть в корневом каталоге:
$ fls -f fat -o 0000000032 1.img
d/d 3: DCIM
d/d 4: SCENE
r/r * 6: raw1.bz2
r/r 8: cdpocket.pdf
r/r 10: raw1
Чудесно, знаем не только имена файлов, но и их смещения, которые нам потребуются, чтобы прочесть файлы. Звёздочка означает, что файл удалён: но его можно попробовать восстановить, если после удаления не проводилось интенсивного перезаписывания файлов.
Если файлов много, или они в каталогах, и требуется найти смещение файла, имя которого известно, следует воспользоваться утилитой ifind.
$ ifind -a -n cdpocket.pdf -f fat -i raw -o 0000000032 1.img
8
Результатом является смещение файла, которое требуется для его извлечения.
Всё, в наших руках вся информация о файлах - осталось их извлечь. Посмотрим, например, на файл cdpocket.pdf, для извлечения которого используем утилиту icat:
$ icat -f fat -i raw -o 0000000032 1.img 8 > cdpocket.pdf
В текущем каталоге после выполнения этой команды появляется файл cdpocket.pdf - читается и просматривается соответствующей программой.

Заключение
Комплект утилит The Sleuth Kit даёт пользователям *nix-систем огромные возможности по восстановлению повреждённых или скрытых данных, и в приведённом выше примере освещается лишь некоторые программы. Больше информации о судебном анализе данных можно найти в прекрасных мануалах, идущих с утилитами, и на сайте авторов.
Читать далее

Глубокий анализ данных, Эпизод 1: foremost



13 коммент.
Есть ситуации: ваша флешка начинает помирать, диск плохо читается и на нём важные данные, или вы пришли к какому-нибудь недругу и подозреваете, что у него на винчестере есть данные, которые вам нужны, а он их показывать не хочет. В общем, вопрос: как выдрать файлы из труднодоступных носителей?
Решение: имеется класс программ "судебного анализа данных" (forensic analisys), позволяющих без шума и пыли (и ректальной имплантации горячих паяльников) выудить данные, даже если они хитро записаны.

Лирическое отступление
Всё началось с того, что ко мне пришёл один пользователь виндовс, и, гордо размахивая флешкой, сказал, что у него есть вордовский файл с паролями, но на этой флешке его никто никогда не отыщет. Мне стало интересно, и я, отвлекая его внимание запущенным на ноутбуке Kororaa с XGL, по-тихому перегнал всю гиговую флешку к себе с помощью dd... На следующий день он очень удивился, увидев в своём почтовом ящике все свои пароли. Ниже рассказывается, как мне это удалось сделать, используя Дебиан и программы, имеющиеся в нём.


Что есть для этого в Дебиан?
Чего только не найдёшь в Дебиановском репозитории! Например, очень и очень интересная программа foremost. Она позволяет искать файлы на сменных носителях / внутри образов дисков по hex-данным, характерным заголовкам и окончаниям. В Sarge версия довольно старая, но с сайта можно скачать тарболл и скомпилировать его. После чего foremost можно запустить и прочитать мануал, который, надо сказать, весьма примечателен:
Foremost was written by Special Agent Kris Kendall and Special Agent Jesse
Kornblum of the United States Air Force Office of Special Investigations
starting in March 2001. This program would not be what it is today without
help from (in no particular order): Rob Meekins, Dan Kalil, and Chet
Maciag. This project was inspired by CarvThis, written by the Defense
Computer Forensic Lab
in 1999.
Выделенные курсивом строки, надеюсь, в переводе не нуждаются?

Как это работает?
Программа прочёсывает файлы на предмет совпадения заранее определённых hex-кодов, соответствующих наиболее распространённым форматам файлов. После чего экстрагирует их из диска / образа и складывает в каталог, вместе с подробным отчётом о том, чего, сколько и откуда было выдрано.
Мануал к программе написан очень подробный, с возможностью добавлять свои форматы, о которых программа не знает. Заголовки и окончания декодируются перед использованием из шестнадцатеричного формата:
Headers and footers are decoded before use. To specify a value in
hexadecimal use \x[0-f][0-f], and for octal use \[1-9][1-9][1-9]. Spaces
can be represented by \s. Example: "\x4F\123\I\sCCI" decodes to "OSI CCI".
А вот и пример того, как выглядят для foremost файлы:
# extension case-sens max-size header footer (option)
#
# GIF and JPG files (very common)
gif y 155000 \x47\x49\x46\x38\x37\x61 \x00\x3b
gif y 155000 \x47\x49\x46\x38\x39\x61 \x00\x00\x3b
jpg y 200000 \xff\xd8\xff \xff\xd9

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

Foremost в действии
Отлично, программа собрана и установлена, с требуемого носителя содран образ при помощи dd, теперь осталось поискать там файлы.

Попробуем поискать файлы, замаскированные под другой формат.
Берём флешку, втыкаем и не монтируем - пробуем выдрать оттуда файлы типа doc, один из которых переименован в jpg (наивный юноша...):
./foremost -t doc -o /opt/foremost-1.3/output/ -i /dev/sdf
После чего идём в подкаталог ../output и наблюдаем радостную картину - файлик обнаружился. А вот и отчёт программы:

Foremost version 1.3 by Jesse Kornblum, Kris Kendall, and Nick Mikus
Audit File

Foremost started at Sat Dec 16 21:48:07 2006
Invocation: ./foremost -t doc -o /opt/foremost-1.3/output/ -i /dev/sdf
Output directory: /opt/foremost-1.3/output
Configuration file: /opt/foremost-1.3/foremost.conf
------------------------------------------------------------------
File: /dev/sdf
Start: Sat Dec 16 21:48:07 2006
Length: 15 MB (16121856 bytes)

Num (bs=512) Size Offset

0: 129.jpg 155 KB 66048
Finish: Sat Dec 16 21:48:12 2006

1 FILES EXTRACTED

doc:= 1
------------------------------------------------------------------

Имя не сохранено, но содержимое в порядке. Нагретый паяльник и утюг можно отложить в сторону. :-)

Другой пример. Пусть хакер Нео хочет скрытно передать товарищу Морфею диск с изображением кодов к Матрице (фотографией голой Тринити). Для этого можно схитрить: приказывать писать программе cdrecord не iso-образ, а просто файл:
cdrecord -v speed=0 dev=ATAPI:0,0,0 matrixcodes
На другом конце Морфей делает

dd if=/dev/cdrom bs=2048 of=~/temp/matrix.jpg
Но вот всех застукал агент Смит, приволок в отделение и ласково спрашивает, что на болванке. Хакер Нео с ясными глазами говорит почти правду - ничего, болванка пустая (ясное дело, что "в лоб" такая болванка не читается). Агент Смит знает Линукс и поэтому он набирает в консоли:
# foremost -t all -o ~/output/ -i /dev/hda
И выуживает из диска крамольные данные: в подкаталоге ..output/ появляется файл audit.txt следующего содержания:

Foremost version 1.3 by Jesse Kornblum, Kris Kendall, and Nick Mikus
Audit File

Foremost started at Sat Dec 16 22:15:26 2006
Invocation: ./foremost -t all -o /opt/foremost-1.3/output/ -i /dev/hda
Output directory: /opt/foremost-1.3/output
Configuration file: /opt/foremost-1.3/foremost.conf
------------------------------------------------------------------
File: /dev/hda
Start: Sat Dec 16 22:15:26 2006
Length: 604 KB (618496 bytes)

Num (bs=512) Size Offset

0: 0.jpg 88 KB 0
Finish: Sat Dec 16 22:15:28 2006

1 FILES EXTRACTED

jpg:= 1
------------------------------------------------------------------

Foremost finished at Sat Dec 16 22:15:28 2006
и каталог ..output/jpg/ с этим файлом...

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

Ещё немного поигравшись с программой, можно сказать следующее. Сразу, без дополнительных танцев, находит foremost графические файлы tif, jpg, png, bmp, звуковые файлы wav, виндовые exe-шники, все офисные форматы (мелкоОфиса и ОпенОфиса), архивы rar и zip и многое другое. Линуксовые архивы типа bzip2 и p7zip "в лоб" программа не берёт, но это дело не сильно облегчает, так как, задавшись целью, можно и их выдрать с диска.

Заключение
На простых примерах была показана мощь программы foremost, которая в умелых руках и при знании простых UNIX-программ типа dd или recoverdm способна выуживать из носителей информации данные, даже весьма хитро спрятанные и записанные нестандартным образом.

Аналогичные программы
Такие программы особенно не афишируются, и крайне неохотно раздаются за просто так. Или надо оставлять свои паспортные данные и доказывать, что вы работаете в полиции, в суде или в КГБ :-) Но всё-таки кое-что имеется. Это проприетарные Safeback, Encase, safecopy, dvdisaster и некоторые другие. Особые параноики полагают, что старый-добрый dd тоже является программой из этой же серии.

Ссылки
Есть очень хороший каталог с описаниями таких программ здесь. Вот тут неплохое описание доступных утилит по анализу данных, ссылки есть и здесь, а ещё лучше погуглить со словом forensic.
Читать далее