Десять «гелиевых» терабайт от HGST (Hitachi)

Этот пост зрел почти месяц, т.к., откровенно говоря, результаты тестирования первого экземпляра 10ТБ SAS производства HGST (бывшая Hitachi) — вызвали у меня сложную смесь удивления и недоумения, что прежде я считал маловероятным событием с учётом масштабов моей практики. Сюрприз…

Итак, знакомьтесь!

HGST Ultrastar He10 (HUH721010AL5204) с интерфейсом SAS3 (12G)

Внутренние подробности:

  • Объём: 10Тб (в реальности — всего 9.1Тб) = 19,532,873,728 секторов (512e)
  • Физика:
    • 14 головок / 7 пластин, 40 зон, в среднем ~436,000 треков/поверхность
    • 7200 об./мин., 468 «серво-меток» (servo frames per track)
    • средняя плотность 4K физических секторов/трек (SPT):
      • 516 (4128 / 512e) в начале (зона 0, OD)
      • 401 (3208 / 512e) в середине (зона 19, MD)
      • 248 (1984 / 512e) в конце (зона 39, ID)

Мои личные ощущения — диск невероятно лёгкий для 7 пластин! Качество сборки в целом и исполнения PCB в частности — очень высокое, что является многолетней нормой для серверных дисков HGST.
Отдельно отмечу обновлённую конструкцию «банки» по сравнению с моделями семейств Ultrastar He6 / He8 — другая крышка и явно новый способ лазерной «запайки» (шов значительно качественнее и тоньше). А что поделать: гелий — крайне специфический газ и требует особых условий.

Любопытно, что с этим накопителем я впервые увидел чёткое «упирание в потолок» пропускной способности канала на SAS 3.0G контроллере — в реальных тестах скорость линейного чтения в начале LBA-пространства (внешний диаметр) достигала ~245 Мб/сек., что даже чуть лучше заявленной (усреднённой) в спецификации.

Что же такого странного оказалось в этом диске?

Неприемлемое для абсолютно нового накопителя (с PowerOn Hours = 0) столь большое количество «медленных» секторов. На графике чтения, из-за его высокой детализации, это выглядело просто удручающе (см.ниже).
Забегая вперёд — на всё пользовательское пространство тест чтения насобирал 8,837 логических секторов (1,105 физических 4K) со средним временем доступа около 225,4 мсек. (мин.= 200 мсек., макс.= 1489 мсек. всего один).
И при этом — ни единого дефекта, пустой G-List, идеальное состояние счётчиков S.M.A.R.T.
Чудеса — да и только…
В гороскопы, астрологию и прочую мега-чушь я не верю, поэтому — гадать о причинах таких эффектов не буду и вам не советую напрягать фантазию (и уж тем более флейм). С учётом того, что я просмотрел даже все внутренние (технологические) журналы ошибок и событий — никаких проблем за самим собой накопитель не обнаружил вообще. Мда…

Что ж… Очень надеюсь, что полученные результаты являются не более чем спецификой непосредственного данного экземпляра, полученного для тестирования, и не окажутся нормой для всей линейки в целом.

Результаты тестов, мои комментарии, лирика…

Условия тестирования:

  • R.tester v1.12.05 (HDDMini Core v5.70, CERT Tool v2.17)
  • Windows 7 SP1 x64 + контроллер LSI SAS1064E (PCIe)
  • HGST HUH721010AL5204 (Ultrastar He10) с прошивкой C21D (точнее, LHGNC21D от 03/11/2016)
  • ключевые тесты в скрипте модуля CERT Tool:
    • Seek («правильный») в режиме «accordion»: 2,048 итераций
    • Seek («правильный») в режиме «random»: 4,096 итераций
    • Чтение в режиме «accordion»: 2,048 итераций блоками по 8 секторов (=4Кб)
    • Чтение в режиме «random»: 4,096 итераций блоками по 8 секторов (=4Кб)
    • Чтение в режиме «sequential step»: с шагом 953,864 секторов, блоками по 1Мб
    • Чтение в режиме «sequential»: блоками по 2Мб

Выполнение всех шагов тестового скрипта заняло… 23 часа 59 минут 33 секунды… :-O
Причина — почти 9 тысяч «медленных» блоков, которые перепроверялись по-секторно. Ну и конечно же, 19+ миллиардов секторов дают о себе знать 🙂

Примечания:

  • «правильный» seek применительно к накопителям HGST SAS означает, что используется настоящая команда Seek с обходом ограничения на 32-бит LBA адрес в стандарте SCSI, что позволяет получать реальные результаты «механических» тестов на накопителях объёмом более 2ТБ. На сегодняшний день, из свободнодоступного ПО таким функционалом обладает только утилита R.tester (что? вы ещё не знакомы с ней? чего ждём?!).
  • на всех графиках (если не указано иное) масштаб по оси X — в кило-секторах LBA (шкала по 1024 сектора, а не по 1000, как было бы логично). Так уж получилось, очень древний глюк… Исправлю в ближайшее время. На результаты тестирования это не влияет, только на масштаб при отображении точек на графике.

Жёсткий диск HGST Ultrastar He10 HUH721010AL5204 SCSI-логи, P-List, статистикаЖурналы ошибок, счётчики и статистика Primary-дефектов (заводских)

Seek в режиме «accordion», 2048 итераций (исходный вид + увеличенный масштаб).
По оси X — LBA, по оси Y — время доступа (мсек.)
** Обращаю ваше внимание на потрясающую стабильность работы системы позиционирования. Это огромная редкость для дисков с «юзерскими оборотами» (менее 10K) и уж тем более для столь многоголовых конфигураций.

Жёсткий диск HGST He10: тест Seek в режиме butterfly (accordion)

Жесткий диск Hitachi HUH721010AL5204: тест seek в режиме butterfly (accordion)

Seek в режиме «random», 4096 итераций.
По оси X — LBA, по оси Y — время доступа (мсек.)
Ничего волшебного: стабильно, симметрично, красиво. Как ожидалось.

HDD HGST He10 HUH721010AL5204: тест seek случайное время доступа

Чтение в режиме «accordion», 2048 итераций блоками по 8 секторов (4Кб).
По оси X — LBA, по оси Y — время доступа (мсек.)
** Поверьте моему опыту: для 14-голового монстра со столь высокой плотностью записи — это шикарный результат. Мелкие «вылеты» с большим временем доступа в начале и в конце графика скорее всего объясняются подозрительным поведением логической головки 1 (физическая головка 12). На графиках ниже я более подробно покажу и объясню, в чём же там дело.

HDD Hitachi HUH721010AL5204: чтение в режиме butterfly (accordion), время доступа

Чтение в режиме «random», 4096 итераций блоками по 8 секторов (4Кб).
По оси X — LBA, по оси Y — время доступа (мсек.)

Винчестер HGST HUH721010AL5204: случайное чтение, время доступа

Линейное чтение в режиме «sequential step» с шагом 953,864 секторов, блоками по 2048 секторов (1Мб).
По оси X — LBA, по оси Y — скорость чтения (Мб/сек.)

Жёсткий диск HUH721010AL5204 пошаговое последовательное чтение, скорость передачи данных

Линейное чтение в режиме «sequential» блоками по 4096 секторов (2Мб).
По оси X — LBA, по оси Y — скорость чтения (Мб/сек.), либо время доступа (мсек.)

Жёсткий диск HGST He10 HUH721010AL5204: скорость последовательного чтениявыглядит, мягко говоря, «не фонтан»… :X

Hitachi HUH721010AL5204: скорость передачи данных при последовательном чтениирассмотрим «поближе» в самом начале — уже лучше!

HGST HUH721010AL5204: тест последовательного чтениярассмотрим «поближе» в самом конце — тоже весьма неплохо!

Жёсткий диск HGST He10 HUH721010AL5204: время доступа при последовательном чтениивремя доступа «по поляне» — не вдохновляет на первый взгляд…

Винчестер HGST HUH721010AL5204: тест "последовательное чтение", время доступарассмотрим «поближе» в самом конце — вполне стабильно

Сводный график температуры накопителя в процессе всего тестирования.
Измерения проводились автоматически с шагом в 5 минут.

Диск HGST HUH721010AL5204: температурадля 14-голов и 10Тб — диск более чем «прохладный»

А теперь — самое интересное!

Это лишь малая толика того изящного и дружелюбного функционала, который является на текущий момент визитной карточкой и уникальной особенностью R.tester‘а:

  • посчитаем реальные головки на графике обычного, логического теста чтения
  • легко и непринуждённо зафиксируем моменты переключения головок
  • увидим работу подсистемы «логической трансляции»: линейный пользовательский LBA — виртуальное «ничто», т.к. реальное местоположение отдельно взятого сектора — настоящая математическая и алгоритмическая магия внутри микропрограммы
  • на реальном примере реального диска обнаружим головку-вредителя, внёсшую большую сумятицу в графики чтения

С этого момента и далее — все графики являются сильно увеличенным масштабом результатов полного теста линейного чтения. По оси Y — время доступа (мсек.), т.к. для действительно тщательного анализа шкала Мб/сек. является весьма бестолковой, «побочным эффектом». Уверен, смысл увиденного ниже сделает моё утверждение более понятным и очевидным.

Отдельные головки жёсткого диска на графике чтениясамое начало диска: «видны» головки и логика трансляции LBA в pCHS

Для наглядности и облегчения восприятия — я пронумеровал логические головки в том реальном порядке, в котором они используются.
Как мы видим, головка 1 (физическая 12) капитально «вылетела» за границы графика при текущем масштабе. Именно из-за неё в начале диска тест чтения выглядит очень неприятно, как «мяясооо». Напоминаю — никаких дефектов нет. Просто «что-то пошло не так»

Момент переключения между головками — определяется внутренними параметрами в таблице зонного распределения (zone layout). Так как все современные накопители уже много лет используют т.н. «адаптивное форматирование», то эти параметры достаточно заметно различаются для разных головок и уж тем более для разных зон.
Непосредственно на данном накопителе, в физической зоне 0 переключение происходит в среднем через каждые ~400 треков. В действительности же, разница в «размере шага» трансляции у разных головок весьма заметна.

Зелёной линией я выделил границу областей т.н. «колец» (notch) — области дискового пространства, в пределах которой алгоритм трансляции выполнит полный обход всех активных головок в соответствии с внутреними таблицами правил (логика в самых свежих накопителях уже ни разу не линейная и там чудес столько обнаружилось, что нужно писать отдельную статью страниц на 40 минимум…).

Области трансляции (кольца / notch) и головки винчестера на графике чтенияпочти самый конец user space: всё так же «видны» головки и трансляции

Ситуация неприятно-стабильная — головка 1 (физическая 12) всё так же «дурит» и «вылетает» за границы графика при текущем масштабе.

На сегодня в целом и по этом диску в частности — всё.

Вопросы, комментарии, идеи, мысли и прочее полезное и уместное по теме — пишите в комментариях и/или лично мне в почту.
С удовольствием отвечу на всё по мере возможности.

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

d(^_^)b

Поделиться ссылкой на пост в соц. сетях

10 thoughts on “Десять «гелиевых» терабайт от HGST (Hitachi)

  1. Unknown

    Миша, ну а какже проанализировать Плист, построить график распределения дефектов по головам и зонам… И как насчет того, что все современные накопители имеют ЭТО? Господа офицеры, молчать! Про медиа кэш, как про покойника — или хорошо, или ничего

    Reply
  2. Валерий

    А чо , просто не мог резюмэ подвести, стока старался и в пустую время потратил, кому нужны твои заумные графики ????? Столько и коментов получил, сколько пользы в этих трудах….. Мне чтоб решить — брать его или не брать — надо институт закончить ?

    Reply
    1. Googler

      Резюме⁈ Результаты тестов будут индивидуальны для каждого экземпляра.

      Здесь описана часть хорошей методики тестирования единичного экземпляра нового серверного HDD перед вводом в эксплуатацию.

      Если Вам затруднительно разобраться в графиках (с пояснениями), то доверьтесь маркетологам — именно за это Вы им платите (стоимость услуг маркетологов включена в стоимость HDD)за скорость расставания с $ и лояльность бренду за простоту неискушённого выбора.

      Reply
      1. ixpert

        Ответ «избранной» обиженки, которая взамен предоставления адекватных данных для среднего пользователя отправляет к лоховтирателям маркетологам, по-клоунски признавая при этом их сущность.

        Reply
  3. Ирис Пис-Пис

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

    Reply
    1. Mr.0x55AA

      Смотрели ли Вы остальные блогозаписи этого блога (блок «свежие записи» справа на странице). Заинтересовали ли они Вас?

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

      Reply
      1. ixpert

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

        Reply
  4. Mr.0x55AA

    Вопросы, комментарии, идеи, мысли и прочее полезное и уместное по теме

    Знаю, что поздно, но было бы любопытно взглянуть на деградацию времени доступа и чтения (тесты: Seek и Чтение в режиме «accordion») в многодисковой конфигурации.

    Либо, например, создать наихудшие условия для записи: поместить в одну корзину 16 дисков; 15 из них объединить в software RAID0 с размером stripe: 8 или 4 КиБ; запустить на RAID0 тест чтения в режиме «accordion» с размером блока, кратным stripe_size*15; одновременно на 16-м диске (физически расположенном в середине корзины) начать последовательную запись секторов, а затем — чтение записанных секторов.

    Reply
  5. Banjolina

    While the freeware software in question offers basic functionality for its intended purpose, its overall performance is lackluster, with frequent crashes and errors that impede its usefulness. Additionally, the user interface is unintuitive and cluttered, making it difficult to navigate and customize. Given these issues, I would not recommend this software to anyone seeking a reliable and user-friendly solution in this field. Needs more work

    Reply

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *