kazenniy28 дек 2015 в 12:23

Прямой доступ к диску из python

6 мин

30K

Python * Linux *

Из песочницы

+29

Комментарии 26

ZyXI 28 дек 2015 в 13:35

У меня вопрос: а проверялась ли возможность параллельно запустить несколько экземпляров whdd? Зачем добавлять параллельность туда, где она уже есть?

kazenniy 28 дек 2015 в 13:50

С whdd у меня сразу как-то не заладилось. У меня в archlinux она падает с Segmentation fault при попытке запуска ata теста чтения. И собранная из AUR и готовый пакет от ubuntu. Думал посмотреть где падает, запустив ее в gdb, а там она работает без сбоев. Не хватило знаний разобраться в чем проблема.

Sergey_datex 28 дек 2015 в 14:24

Открытий будет еще очень много. Основное — вам необходимо будет точно измерять время выполнения команд (вы же хотите качественно тестировать диски?), а при параллельной работе с этим будут большие проблемы. Многозадачность тоже вносит погрешность.
Обратите внимание на вкладку настроек Victoria Win, и режимы работы таймера.

kazenniy 28 дек 2015 в 14:45

В структуре sgioHdr есть параметр duration. Судя по описанию в scsi/sg.h «time taken by cmd (unit: millisec)», он должен заполнятся системой и содержать время занятое на выполнение команды. Пока не пробовал, но надеюсь это работает и тогда измерять время самому не придется.
Про открытия не сомневаюсь, опыта работы с многопоточностью еще не было.

quartz64 28 дек 2015 в 14:26

1. Смотрим через smartctl информацию о диске и атрибуты. Бывает, что сразу Failed выдаёт по какому-нибудь параметру — в морг.
2. Запускаем через тот же smartctl короткий и длинный self-test'ы. Не проходит — в морг.
3. Гоняем badblocks с записью и/или скрипт с fio (он умеет проверять записанное по хешам). Смотрим, не растут ли ремапы.
4. Для SAS можно выполнить sg_format и повторить тесты.
Чем плох такой алгоритм?

kazenniy 28 дек 2015 в 14:55

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

quartz64 28 дек 2015 в 15:05

Тогда тот же fio с write_lat_log и дальнейшим построением графика через gnuplot?

kazenniy 28 дек 2015 в 15:15

Не сталкивался с этой утилитой, надо будет посмотреть. Ей нужна файловая система или она с блоковым устройством работает?

quartz64 28 дек 2015 в 15:18

И так и так может.

Sergey_datex 28 дек 2015 в 14:28

Не успел отредактировать предыдущий комментарий:

Как минимум если ядер процессора будет меньше чем тестируемых дисков, появляется большое влияние процессов друг на друга и сильное снижение скорости тестирование (так на win)

amarao 28 дек 2015 в 16:07

Хотел написать типичный русский комментарий:

Иметь библиотеку для работы с SG-подмножеством команд SCSI было бы неплохо, но то, что вы написали, библиотекой не является. Ни в каком смысле. Не описаны интерфейсы для работы с библиотекой, полностью отсутствует обработка ошибок, тестов нет.

Но всё это неправда. Вы делаете правильную и хорошую вещь, потому что на питоне нет нормального интерфейса для работы со смартом (лучшее, что есть пока что — это pysmart, который враппер над smartmontools), а для sg нет вообще ничего.

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

kazenniy 28 дек 2015 в 17:08

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

amarao 28 дек 2015 в 19:39

Ну, первое, что нужно, это документация с примерами вызовов. Второе — стабильный и более-менее предсказуемый интерфейс. Третье — своя иерархия exception'ов, чтобы не ловить неожиданные и непонятные OSError, IOError непонятно где. Четвёртая — тесты (py.test, например). Особенно часть с упаковкой данных в структуры — оно точно должно быть покрыто тестами, ибо без боли разобраться в этом нельзя будет (в силу предметной области).

Вот это:
231: «Temperature_Celsius» — на современных SSD'шках этот же атрибут соответствует SSD Life Left:

См: media.kingston.com/support/downloads/MKP_306_SMART_attribute.pdf (поиск: 231)

kazenniy 29 дек 2015 в 04:11

Со стабильностью интерфейса пока будет не очень. Некоторые вещи там можно сделать по разному и я пока не понимаю, как лучше. Думаю интерфейс придется устаканивать в процессе пробного использования. Свои exception`ы в планах. Понимаю, что возвращать при ошибках None это не дело. С тестами у меня все плохо. По скольку сейчас для меня питон это эдакий продвинутый bash, то и темы автоматического тестирования я не касался вовсе. Придется учится.

Касательно смарта там вообще сплошная боль. Номера атрибутов у разных производителей могут иметь разное значение. Raw значения могут иметь разный размер и разное количество значений и т.д. Смотрел на этот счет исходники smartmontools. Ребята проделали очень большую работу сводя это воедино.

Может подскажете пример небольшой но правильно написанной библиотеки? Посмотреть, в качестве учебного пособия.

amarao 29 дек 2015 в 10:28

Во-первых — классы. Будет класс, можно будет менять его свойства (например, менять «что значит этот смарт-атрибут» в зависимости от других полей или даже действий пользователя).

Первая попавшаяся не очень сложная библиотека: github.com/softvar/simplegist

Без тестов, правда.

Вот более сложная библиотека, с тестами: github.com/softvar/json2html

Если утрированно, то весь тест выглядит так:

import pytest
import my_module

def test_foo():
   assert my_module.foo(1) == 1

def test_boo():
    assert my_module.foo(2) == my_module.boo(3)

def test_raise():
    with pytest.raises(ValueError):
        my_module.foo(None)

if __name__ == "__main__":
    import sys
    pytest.main("-v %s" % sys.argv[0])

Дальше там начинается вопрос «а как тесты писать» — и тут два слова для поиска: fixtures и mocks.

kazenniy 29 дек 2015 в 11:01

Большое спасибо за наставление на путь истинный. Буду изучать, праздники длинные.

bosha 30 дек 2015 в 07:28

Обычно ещё возникают сомнения, что мол, тесты больше самой программы, и тянут больше зависимостей — это тоже норма. :)
Ещё на первых порах будет полезен coverage — он покажет какие части желательно тоже покрыть тестами.
И прикрутите setuptools, да добавьте в pypi. Обычно глобально никто не ставит/копирует библиотеки. Всё через virtualenv/pip.

Tutorial — peterdowns.com/posts/first-time-with-pypi.html
Пример — github.com/bosha/pypushalot

kazenniy 30 дек 2015 в 07:57

С тестами для подобного софта тоже не очень понятно. Это же не программа, которая получила данные/перемолола/выдала данные.Тут для тестов нужна железка, диск. При этом операции записи на диск деструктивны.

bosha 30 дек 2015 в 10:53

Как выше написал amarao — для этого используют моки и фикстуры (mocks and fixtures). Есть какое-то определенное поведение диска, которое с помощью определенных библиотек можно эмулировать.Т.е. Вы импортируете эту библиотеку, программируете определенное поведение: при определенных запросах, определенные ответы.
Вот, например, мокинг HTTP — github.com/bosha/pypushalot/blob/master/tests/test_transport.py:

import unittest
import httpretty
import pushalot.exc
from pushalot.transport import (
    API_URL,
    HTTPTransport,
)

class TestHTTPTransport(unittest.TestCase):

    @httpretty.activate
    def test_raises_exception_if_wrong_json_returned(self):
        with self.assertRaises(pushalot.exc.PushalotException):
            # httpretty будет возвращать по POST запросу
            # на API_URL body c "Whatever.."
            httpretty.register_uri(
                httpretty.POST,
                API_URL,
                body='Whatever..'
            )
            transport = HTTPTransport()
            result = transport.send(
                Title='Test',
            )

Вообще, если Вы не планируете стать python разработчиком, то думаю, не стоит заморачиваться с этим сильно. Чтобы были хорошие тесты, надо писать код с мыслью в голове, что для всего этого их ещё писать, или вообще сначала писать тесты, а потом код (TDD). Однако, на pypi стоит библиотеку залить. Если что, на праздниках могу сделать pull request на github с необходимыми изменениями (их совсем чуть-чуть). :)

kazenniy 30 дек 2015 в 11:05

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

amarao 30 дек 2015 в 23:08

Большая поправка: не нужно делать TDD, чтобы получить большую пользу от тестов. Особенно в питоне. Для питона иметь 100% покрытие кода тестами (даже дурацкими) имеет большой смысл хотя бы для того, чтобы не получать NameError из-за дурацких опечаток.

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

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

В реальном мире оно постоянно меняется под давлением «вновь открывшихся обстоятельств» и куда оно вынесет — никто не знает.