Pull to refresh

Comments 26

У меня вопрос: а проверялась ли возможность параллельно запустить несколько экземпляров whdd? Зачем добавлять параллельность туда, где она уже есть?
С whdd у меня сразу как-то не заладилось. У меня в archlinux она падает с Segmentation fault при попытке запуска ata теста чтения. И собранная из AUR и готовый пакет от ubuntu. Думал посмотреть где падает, запустив ее в gdb, а там она работает без сбоев. Не хватило знаний разобраться в чем проблема.
Открытий будет еще очень много. Основное — вам необходимо будет точно измерять время выполнения команд (вы же хотите качественно тестировать диски?), а при параллельной работе с этим будут большие проблемы. Многозадачность тоже вносит погрешность.
Обратите внимание на вкладку настроек Victoria Win, и режимы работы таймера.
В структуре sgioHdr есть параметр duration. Судя по описанию в scsi/sg.h «time taken by cmd (unit: millisec)», он должен заполнятся системой и содержать время занятое на выполнение команды. Пока не пробовал, но надеюсь это работает и тогда измерять время самому не придется.
Про открытия не сомневаюсь, опыта работы с многопоточностью еще не было.
1. Смотрим через smartctl информацию о диске и атрибуты. Бывает, что сразу Failed выдаёт по какому-нибудь параметру — в морг.
2. Запускаем через тот же smartctl короткий и длинный self-test'ы. Не проходит — в морг.
3. Гоняем badblocks с записью и/или скрипт с fio (он умеет проверять записанное по хешам). Смотрим, не растут ли ремапы.
4. Для SAS можно выполнить sg_format и повторить тесты.
Чем плох такой алгоритм?
С полумертвыми дисками все просто, мне нужно ловить более тонкие случаи. Например диски выпадают из массива но тесты производителя проходят без ошибок.
Тогда тот же fio с write_lat_log и дальнейшим построением графика через gnuplot?
Не сталкивался с этой утилитой, надо будет посмотреть. Ей нужна файловая система или она с блоковым устройством работает?
Не успел отредактировать предыдущий комментарий:

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

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


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

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

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

См: media.kingston.com/support/downloads/MKP_306_SMART_attribute.pdf (поиск: 231)
Со стабильностью интерфейса пока будет не очень. Некоторые вещи там можно сделать по разному и я пока не понимаю, как лучше. Думаю интерфейс придется устаканивать в процессе пробного использования. Свои exception`ы в планах. Понимаю, что возвращать при ошибках None это не дело. С тестами у меня все плохо. По скольку сейчас для меня питон это эдакий продвинутый bash, то и темы автоматического тестирования я не касался вовсе. Придется учится.

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

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

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

Tutorial — peterdowns.com/posts/first-time-with-pypi.html
Пример — github.com/bosha/pypushalot
С тестами для подобного софта тоже не очень понятно. Это же не программа, которая получила данные/перемолола/выдала данные.Тут для тестов нужна железка, диск. При этом операции записи на диск деструктивны.
Как выше написал 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 с необходимыми изменениями (их совсем чуть-чуть). :)
Я уже активно все переписываю используя классы и исключения, устаканиваю интерфейс. Так что к этой версии исправления уже не актуальны. Классы оказались во многом удобнее функций. Развивать дальше буду уже новую версию. Надеюсь после праздников выложу на гитхаб.
Большая поправка: не нужно делать TDD, чтобы получить большую пользу от тестов. Особенно в питоне. Для питона иметь 100% покрытие кода тестами (даже дурацкими) имеет большой смысл хотя бы для того, чтобы не получать NameError из-за дурацких опечаток.

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

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

В реальном мире оно постоянно меняется под давлением «вновь открывшихся обстоятельств» и куда оно вынесет — никто не знает.
Я переписал библиотеку используя классы и залил на github и pypi.
Прекрасно. Так держать. :)
Рискну предположить что в «В ответ получаем сектор с информацией о диске:» вместо «сектор» должно быть «буффер».
Да, так будет правильнее.
Sign up to leave a comment.

Articles