Вопрос на правах обсуждения и советов.
Занимаюсь написание софта для тестирования железа. В данном случае стоит задача проверки работоспособности интерфейсов, а не целостность жёстких дисков (тестируем материнки). 

Суть теста такова, что надо получить список жёстких дисков, подмонтировать их (если не сделано ранее), и на жёстком диске создать файл определённого размера, считать его и сделать замер времени на чтение и запись (кстати важно убедиться, что файл реально оказался на диске, а не осел в буферах ядра). Тут наверное меня спасёт sync. При чём, что логично, что файл создавать только на физическом жёстком диске, минуя логические, т.к. важна проверка физических интерфейсов, а не логики работы. Можно даже в общем-то и не файл, а просто некий дамп данных, но так чтобы никому не мешать.

Начну с простого вопроса: быть может есть что-то аналогичное готовое, чтобы поглядеть примеры кода и т.п., минимизировав изобретение велосипеда?

Второй вопрос: как лучше получать список жёстких дисков?  Игнорируя другие системы (типа tmpfs). так же не просто список носителей, а ещё данные о размере, примонтированность  их в системе и т.п. Чтобы сразу можно было производить запись в точке монтирования устройства.
Возможно ли это сделать чтением файлов в sysfs или proc?

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

Решения, которые я нашёл по второму вопросу мне кажется не очень изящными, т.к. будут вызываться сторонние программы. Первое и очевидное решение - это fdisk:



Достаточно информативно, но не хватает информации о точках монтирования. Плюс, как бы программе не промахнуться куда писать...

Второе решение, это parted:


И третий вариант lsblk



Или более информативный запрос, с отсеканием всего лишнего:



Далее можно сделать вызов на подобии такого:



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

Как бы сделали вы? Если, что работаем под рутом (т.к. железо тестим).

Ищите в /sys/block ( http://mydebianblog.blogspot.com/2013/02/sysfs-linux.html )


Угу, и это 'откуда-то' /proc и /sys (ну еще может быть /dev)

И для всех этих програм доступны исходники, откуда можно явно посмотреть, что и откуда читается

hdparm

Актуальный список хардов можно найти в /dev/disk/by-path...
Чтобы не было проблем с локальными дисками и кэшами рекомендую производить запись и чтение напрямую на диск (минуя логические тома и файловые системы) - эти диски не будут содержать в своем названии слово part на конце.
Более того, все это можно сделать башевским скриптом. Для этого понадобятся: for/while, ls, grep, dd, time

Спасибо, то что нужно!

Добавлено через 3 минуты и 23 секунды


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

/me правда подумал, что можно заюзать diff, а проверочный дамп в памяти держать в /tmpfs... Но это как-то не спортивно.

dlinyj, ты вообще как представляешь повреждение данных? Ты понимаешь, что все данные идущие от матери к дискам и обратно сопровождаются кучей контрольных сумм и проверок на аппаратном уровне?
Единственное, что ты можешь сделать, это оценивать качество передачи данных по времени - чем больше время, тем больше повторов передачи (т.е. ошибок) было в дисковой подсистеме.

Разумеется всё это понятно. Я имел в виду, что на жёстких дисках может стоять некоторая система, и её может поломать .

А повреждение данных элементарно. Контроллер SATA, запись провёл нормально (с контролем, все дела), а потом перегрелся и отвалился (причина - мои фантазии, с этим будут аппаратчики разбираться). Мало ли аппаратных сбоев. Я тут больше на железо сетую и его проверяю, чем на софт с контрольными суммами. 

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



Внутри ничего особенного, просто потемневшая микросхема, да оплавившаяся плёнка. Но сам факт, так что контролировать запись и чтение надо многократно.

Наличие и отсутствие part на концэ никак не влияет на использование кэша.

Контрольные суммы не софтом формируются. А аппаратурой. Другими словами, если ты записал данные на диск, то ты их или прочитаешь корректно, или не прочитаешь вообще. Поэтому хранить дамп совсем не обязательно. можно тупо делать dd if=/dev/zero of=/dev/disk/by-path/...

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

Привожу вам конкретный пример, того что вы не правы. У меня есть CF-карточка, которая исчерпала местами свой ресурс чтения-записи (некоторые сектора), подключена в качестве IDE-винта. Вот сделаем проверку таким образом Обращаю внимание, что на самом деле нельзя проверять только нулями или FF, надо проверять разными байтами. Если ячейка исчерпала свой ресурс, то она может отдать какое-то значение, но его поменять не может. Но для теста представим что нас это устроит. Формируем тестовый файл:



Далее сформированный файл записываем на CF



Как видим, запись не вызывает проблем! Далее читаем его:



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


Упс, а тут у нас ерунда!  

Так что чтение, запись и что прочитали надо контролировать. Кстати, программа hdparm фактически тоже не контролирует что она читает и пишет. Она работает просто. Считывает некоторое количество данных и пишет их обратно (т.е. в случае сбоя потерь не будет). Я пробовал физически оторвать жёсткий диск, она не делает проверки "существования", просто в конце говорит, что не удалось дописать. Так что никакой проверки целостности записанных данных никто не делает (только на аппаратном уровне контроллера).

Это сообщение отредактировал(а) dlinyj - 28.2.2014, 12:06

Приведенный пример противоречит этому утверждению. Чему верить?

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

Плюс у нас ещё бывают достаточно жёсткие тесты (температурные, радиационные и т.п.), когда опять же контроллеру может оторвать башню. По этому тестирование надо проводить полное. 

Или вы не согласны с моим примером выше, что надо контролировать чтение и запись?

Впрочем, мне смутно видится смысл дальнейшего диалога.   Я уже сам дал себе ответы на все вопросы . 

все зависит от поставленной задачи. На мой взгляд, контроль работы контроллера должен осуществляться с помощью специального тестового стенда, с защитой от перенапряжений и прочих глюков контроллера. А вот тестировать на дорогом железе (вроде SSD) я бы воздержался. Потому что еще не известно, как себя поведет диск в случае сбоя контроллера. У одного может быть защита от подобного глюка, а у другого не быть. В итоге тест будет ни о чем.

Постоянно работаю с устройствами типа микроконтроллеров. Но я не аппаратчик и никогда не работал с SATA контроллерами.

Да это всё так. Аппаратной разработкой стенда занимаются другие люди, и это вне моей компетенции, но там всё на высоте. На счёт SSD - цена винта, в сравнении со стоимостью конечного изделия - копейки. Ну и потом тестировать надо с тем, что будет использовать заказчик. И тестируются с разными винтами, я просто показал живой пример.
В данном случае тест простой: прошёл или нет. Я вижу вариант отказов, например при минус 55 градусов Цельсия замёрз контроллер, потом оттаял, и некоторое количество секторов не записалось. Мы не узнаем этого, пока не прочитаем файл обратно. Как-то так .