Comments 145
Начиная читать, предавался интриге - что же авторы для себя открыли: замещаемые сектора или разную линейную скорость на разных цилиндрах.
они открыли 20 век
Причем любой человек, который жиль чуточку раньше и выбирал HDD диск для себя, чаще всего перед покупкой смотрел элементарный обзор и тестирование интересующей модели и буквально в каждом был, и график записи на диск, и упоминание, что скорость/график в начале записи и в конце сильно отличается.
В общем потратили кучу времени на то, что было в общем-то очевидным...
Когда-то диски были достаточно медленные, скорость HDD имела значение, статьи с графиками были актуальны и многие их читали. Потом диски стали достаточно быстрыми, чтобы не заморачиваться насчет максимальной скорости последовательного доступа, измеренной независимыми тестерами.
Другое дело, что проектируя систему где скорость критична стоило бы поискать независимые измерения. Ведь есть слово "маркетинг" и инженеры должны знать что цифры указанные в спецификации часто являются завышенными и не полностью отражают реальность.
Мы слишком сильно стали забывать "поля" из MHDD и графики из Victoria...
Они НЕ открыли зоны https://intuit.ru/studies/courses/3460/702/lecture/14152?page=2 , в зависимости от зоны разное количество секторов на дорожку.
Тоже подумал что придумали трехслойную черепичную. Вобще в victoria всегда этот график так и выглядел
А я ещё подумал, ну не файловые же системы они там используют? Наверное что-то своё, что пишет линейно, а метаданные на ssd.... А может SMR опять тихой сапой производители начали в диски пихать? Даже мысль в голову не пришла, что они могли не знать, что диск в конце LBA-пространства пишет медленнее чем вначале из-за разной линейной скорости пластины под головкой диска на внешнем радиусе и на внутреннем.
Например, производитель систем видеонаблюдения трассир, интересным образом учел способность дисков выходить из строя и пишет видео фрагментами поочередно на диски, которые заполняются последовательно (как бы raid0) но с учетом ключевых кадров так, чтобы при потери диска, вы в целом могли не напрягаясь смотреть видеозапись с небольшими пропусками. И дешево и почти надежно - хороший компромисс.
А тут, я правильно понял, они взяли маркетинговую скорость диска 250МБ/сек, умножили на количество дисков и записали это в характеристики их издения? А потом даже не провели испытаний, по тому что иначе бы они сразу столкнулись с реальностью.
И даже если это не их изделие, клиент явно ожидал другого и расчеты не проверялись на практике.
Как так-то?
Проблема не у Хьюстона, а у Positive Technologies? Производители все договаривают, просто нужно открыть даташит на конкретную модель диска. Я сам, уже давно не читал даташит на HDD диски, но не думаю, что за это время они перестали публиковать спецификацию и разные интересные технические параметры.
согласен
И это еще успешно забыт SMR и CMR. Миксанув 2 диска одинаковых характеристик, но один с CMR, другой в SMR, в рейде можно получить веселую историю, когда у одного утилизация 100%, а у другого 20%. А в среднем по больнице - скорость говно :)
И просто умирающий диск в рейде, который еще не сдох, но имеет кучу делеев, но патрол скан не тригерится. И начинается веселье поиска того самого диска, если это рейд из 10+ дисков.
Подскажите, а простые способы, типа "кристалл диск" диск не видят?
Скрытый текст
Или может возможно триггеры настроить именно на переназначенные сектора?
Далеко не все рейд контроллеры отдают инфу о физических дисках за ними. Далеко не весь софт умеет ее читать.
Еще например, у SAS дисков совсем другой смарт. Там нет такого параметра, как reallocated sector count или пендинг секторс. Он выглядит так: https://www.hdsentinel.com/forum/viewtopic.php?p=18196&sid=d626953f4fe5bddeb43113b88bad7c8f#p18196
Например HDDSentinel может в пасстру через многие контроллеры, чтобы почитать смарт, но далеко во все. Про кристалдиск не знаю, сомневаюсь в принципе. Когда искал чем оттестить полку дисков (sas и sata) и просверлить дохлые - последний мне не подошел по каким то причинам (уже не помню)
Плюс есть всякий шлак в виде Синолоджей с их приколами, что даже битую поляну на диске он игнорит и падает в висяк / либо считает, что все гут. Туда вообще ничего не воткнуть из софта с алертами. Писал под другими постами как -то.
Поколение Z разработчиков открыло для себя HDD. Интересно, если им дать грампластинку и спросить, почему музыка звучит с одинаковой скоростью, от начала до конца.. Грустно всё это, а уж сколько воды в посте налили.
Ого, какой вы умный! Все знали заранее. А я вот не знал, статья супер, Алексей спасибо
Интересный конечно результат. Во времена, когда такие диски были в ходу, в журналах были графики с тестами скоростей. И очень странно, что прошло лет 15 и знание, что скорорость диска снижается оказалось утеряно.
Да ладно, там же еще при описанной ситуации "утилизация дисков подходит к 100%" должно было триггернуть вопросом "а фрагментация свободного пространства у файловой системы тут не может влиять"?
Так у них последовательная запись потоком идет, почему там должна возникнуть фрагментация?
Во-первых потому, что "а затем начинается процесс ротации".
Во-вторых, сказано "Сессии в хранилище объединяются в файлы размером примерно по 1 ГиБ, запись в файлы происходит последовательно блоками по 2 МиБ ", но данная формулировка не отвечает на вопрос - в один поток идёт запись, или в несколько.
Да, в каждый файл пишут потоком последовательно, но что не даёт PT NAD писать в несколько потоков в несколько файлов? Тем более, что для PT NAD есть картинки, где захват идёт с двух сетевых интерфейсов сразу...
В третьих не сказано, место под файл выделяется сразу, или он растёт по мере записи?..
Запись в несколько потоков, рост файла по мере записи, особенности используемой файловой системы уже может дать фрагментацию файлов, но пока место есть и на диск только пишут и места еще много - это ни на что не влияет. Но когда начнётся удаление старых файлов и запись на их место (потому что место кончилось и пошла ротация) - вот тогда и может оказаться, что для записи потока головкам придётся прыгать по диску...
Но когда начнётся удаление старых файлов и запись на их место (потому что место кончилось и пошла ротация) - вот тогда и может оказаться, что для записи потока головкам придётся прыгать по диску...
Если файлов не так много - это всё ляжет в дисковый кэш операционной системы.
Но вообще - я удивлён, что они не пишут кольцом на диск без файловой системы вообще.
Если файлов не так много - это всё ляжет в дисковый кэш операционной системы.
Файлов может и не много, зато они большие. И еще неизвестно, как росли - по мере записи, или сразу нужного размера создавались... Так что кэш кешем, а писаться будут как получится. И возможно с sync после записи во избежание потери данных, например )
Но вообще - я удивлён, что они не пишут кольцом на диск без файловой системы вообще.
Ну точно в файловую систему, судя по мануалу.
я удивлён, что они не пишут кольцом на диск без файловой системы вообще
Зачем? Наверняка процент инсталляций этой штуки с одиночными HDD в качестве хранилища мало отличим от нуля, для рейдов такие манипуляции со стороны прикладного софта бессмысленны, а делать собственную реализацию записи на JBOD несколько более затратно, чем просто указать в системных требованиях, что минимальная скорость записи в хранилище должна соответствовать сетевому трафику.
-
Чисто к слову. Есть американский дядечка, который разбирает старую технику и объясняет, как она работает. Думаю, "они вам не пиксели" видели многие. Так вот, лазерные CD диски и приводы к ним устроены сложнее, чем рисуют на схемах. А по статье, что в ней такого нехорошего, аж Петросяны проснулись ? Как для расширения кругозора — почему нет.
Позвольте порекомендовать Вам книгу «Архитектура компьютера» Э. Таненбаума. Книга написана простым языком для широких масс (но при этом это не чтиво для домохозяек). Безусловно, книга не идеальна и имеет ряд недостатков, но доя расширения кругозора пойдет. Ее можно купить и в цифре и в бумаге за смешные для ее объема деньги. У пиратов она тоже находится без проблем.
Поколение Z разработчиков открыло для себя HDD.
Так статья и предназначена для поколения Z, у кого первым диском был SSD. Да и для остальных полезное напоминание об особенностях HDD, в связи с тем что прогресс SSD идет с черепашьей скоростью, а потребность в объемах растет.
Ну и справедливый упрек в адрес производителей HDD, в том что они по прежнему указывают в характеристиках только максимальную скорость для внешней дорожки, и не указывают минимальную гарантированную скорость.
и не указывают минимальную гарантированную скорость
они её не знать тк угадать как будет использоватся носитель не могут а на тестах максимальной скорости пишут (через контролер девайса) самым быстрым способом которого у потребителя может и не быть
Он про то, чтобы добавить в характеристики ещё эту величину:
Как это назвать? Минимально гарантированная скорость записи? А я буду насыпать на дискрандомную запись минимальными блоками и без кеша. И получу скорость ещё меньше, чем минимально заявленная.
И можно будет диски обратно возвращать, мол, они неисправны.
Как это назвать?
Так же.
Sustained transfer rate⁴ (MB/s, max min)
⁴ Based on internal testing ... location of the max min rate is at approximately 10% 100% into the capacity of the HDD.
От юридических солоночных хакеров отбиваться с помощью уже имеющегося "performance may vary depending on host environment, drive capacity, logical block address (LBA), and other factors" или добавить "sequential" в название величины.
Вы не поверите, но в спеках к дискам указывают даже seek time (avg, min, max) и много других интересных цифр.
При особом желании вы можете писать последовательно на максимально далёкие сектора (предварительно отключив кеш записи, если он есть) и получить с современного шпинделя восхитительную скорость уровня линейного чтения CD-ROM ;)
Есть другая идея:
Как назвать? Максимальный пинг при соблюдении условий:
Исправность поверхности и головки
Статическое положение диска и защита от собственной вибрации
Определённый размер вычитываемого блока (4кБ или 0.5кБ)
Нету пограничных ситуаций, которые могут заставить перечитывать блок больше одной попытки.
Идея устарела/устаревает вместе с дисками на 15K и 10K RPM, вместе с 2.5". "Random Read/Write: быстрее, чем у магнитной ленты", ну и ладно.
Почему устарела?
Тщательное описание задержек полезно, если нам нужно быстрое случайное мелкоблочное IO. Но если оно нужно, то берут SSD.
HDD для такой нагрузки перестали производить, 20-терабайтные диски не будут выбирать по этой характеристике. И, наверное, там разницу лучше не искать в характеристиках, а создавать самому с помощью выноса метаданных ZFS на SSD и других подобных приёмов. btrfs тоже хотел такую функцию добавить, но это было давно и неправда это бесконечный долгострой.
Как назвать? Максимальный пинг
Это latency, "время выполнения запроса, задержка перед ответом".
И на неё помимо зоны на диске влияет (на таком тесте этого не увидеть в принципе) нагрузка на диск, т.к. запросы ставятся в очередь.
Да если знать побольше о дисках, то например нужно учесть что скорость в реальных условиях при сильной фрагментации может падать почти до 0. И какую скорость надо писать? ноль? Наш диск точно записывает со скоростью больше 480КБ в секунду? (120 iops * 4К = 480КБ/сек). А 120 знаете откуда взялось? 7200RPM / 60 секунд в минуте, получается что диск делает ровно 120 оборотов в секунду. Значит при наиболее наудачном раскладе, он сможет совершенно точно спозиционировать головку 120 раз, и после каждого позиционирования будет ждать полного оборота диска уже на другой дорожке. Да иногда он бывает успевает за оборот на нескольких дорожках поработать, но ведь это уже не гарантированный результат.
Производителям SSD тоже посоветуйте писать свои минимальные 300, 80 или 15MB/s
Нет такой минимально гарантированной, т.к. ЖД легко ввести в клинч массовыми запросами и фрагментацией. Минимальное, получается, вообще стремится к нулю. Потому и указывают только максимальную, т.к. она известна и выше неё прыгнуть не получится. Это просто надо понимать, а не как авторы проводить целое исследование.
Угу, скандалы, интриги, расследования... А на выходе общеизвестный факт, об этом даже в Педивикии написано - "Влияние геометрии на скорость дисковых операций".
Впрочем, к чести автора - он на общедоступную информацию сослался в тексте. А не выдал за свежее открытие, как может показаться из некоторых комментариев. Но заголовок кликбейтный, ага )
Впрочем, это скорее о подходе "до нас ничего не существовало" (и забывая поговорку про то, что всё новое - это просто хорошо забытое старое) и разнице мышления у поколений, что, впрочем, на Хабре в других статьях обсуждается...
p.s. Но вот зря про IOPS не упомянули в статье, кстати. Он в ряде случаев важнее линейных скоростей.
Вы зря так негативно настроены к авторам. Указанную проблему видел на практике далеко не каждый айтишник, даже знающий о ней. Знать теоретически - одно, получить на конкретном рабочем кейсе - другое, а уж доказать клиенту, что проблема не в вашем ПО, а в том, что он неправильно организовал хранилище данных - вообще третье. И вот именно о третьем текст.
а уж доказать клиенту, что проблема не в вашем ПО, а в том, что он неправильно организовал хранилище данных
А уж как доказать клиенту, чтобы его еще и не обидеть - четвёртое.
А как при этом изложить так, чтобы не было смешно тем, кто имеет общее представление о компьютерном железе (а не только судит по тому железу, с каким лично он работал) - пятое...
Собственно, будь заголовок менее кликбейтным и будь пояснение о том, что тут не ставится целью срывать покровы с мирового заговора производителей дисков, но показать, как важно правильно проектировать хранилище - и реакция была бы другой.
Но тогда надо было бы еще и напомнить читателю, что IOPS важнее линейной скорости, и что надо разбираться с характером нагрузки (read iops, write iops / random iops, sequential iops). Про IOPS на Хабре даже что-то находится или тут.
Еще и столько плюсиков статье поставили....
по мере приближения к центру диска вращение каждого сектора медленнее и секторов в кольце меньше
Слышал звон, да не знает где он
Кажется, речь идёт о Zoned Recording (вики). Ну а поскольку это всё еще с 80-х годов прошлого века растёт - естественно, что это нынче древнее забытое знание...
Линейная скорость пролёта сектора под головкой, да. "Вращение" тут неуместно.
То есть ждём РАЙД-контроллеры, которые будут учитывать описанный эффект и соответствующим образом смещать виртуальные начала дисков для обеспечения более-менее равномерности... а с учётом того, что набирающие популярность твердотельные диски такой ерунде не подвержены, уже даже и не ждём?
статья для клиентив компании - их сюда будут слать
Ого, получится виртуальный вариатор, получается
появилась дико упоротая идея
что если рейд (условный mdadm например для этого можно пропатчить) будет писать диски так:
допустим собираем зеркало из двух дисков одного объёма, первый пишется с начала в конец а второй с конца в начало, тогда график будет меньше проседать т.к. данные успевшие упать на тот диск который ближе к центру блина можно считать успешно записанными а на второй блин догонять их уже после. это не подойдёт для тех массивов где запись идёт постоянно с пиковой скоростью, и надёжность понижается, но там где скорость записи важнее сохранности это имеет смысл (если такие кейсы вообще существуют).
на FreeBSD есть geom, geom/ + возможно zones.intro-1/index.html(BSD подобные включая OpenSolaris) наверно связано с дисками(не уверен) раиды вроде да можно расчитать сколько в кластере раидов или на узле наверняка есть формула покрытия дисками(предположил), наверняка еще есть технологии какието, интересная статья
geom это класс блочных устройств
хочется добавить на Солярисе есть beadm которому нету аналога поидее на сколько я знаю, конкретно в той реализации лучше для действий и проще откатывать систему
В freebsd boot environments еще со времён солярисового zfs
долго обьяснять различие, технически да, на Фрибсд есть, но на Солярисе система будет безошибочной с этой утилой там вроде самый лучший юзкейс, из-за некоторых особенностей на ФриБСД вроде так же, но после Соляриса уже не так ощущается, это можно ощутить даже на OpenSolaris на ПК всю мощ этой утилы, по началу может показаться тормозной системой, но она крутая, помимо этой утилы много всяких штук удобных, почти не пользуешься конфигами ну или когда експерт пользуешься
Я что то пропустил? Вроде бы всегда во всех жестких дисках количество секторов на цилиндр - фиксированное? А ближе к центру просто плотнее запись. Древние диски даже имели провод включения предкомпенсации записи и номер цилиндра, с которого включалась компенсация - прописывался в биосе.
Это на CD дисках равномерная плотность записи и запись по спирали, как на грампластинке. И там да, по мере приближения к центру меньше "секторов" на "цилиндре", если можно так выразиться применительно к CD.
А описанный в статье эффект - это общеизвестный баг, связанный с черепичной записью SMR. И как раз запись сверхбольших файлов на диск - один из способов выяснить, черепичный диск или нет.
Я что то пропустил? Вроде бы всегда во всех жестких дисках количество секторов на цилиндр - фиксированное?
Пишут, что физическая и логическая геометрия различается. В логической да, фиксированная, а в физической может быть как минимум 3 зоны - ближе к центру, посредине, ближе к краю, где количество секторов на дорожку разное (на внешней зоне выше, на внутренней ниже). Позволяет повысить плотность записи на "блин".
Физическую геометрию контроллер диска (который в самом диске имеется в виду) не показывает, кроме разве что в инженерных режимах (но это не точно ) ).
Начиная примерно с 90-х во всех дисках делают зонирование: соседние треки примерно одинаковой длины группируют в зоны. Внутри каждой зоны треки имеют одинаковое число секторов, чем дальше от центра, тем их больше. Скорость вращения, разумеется, везде одинакова, различается линейная скорость чтения (на внешних треках выше), и чтобы понять это, знать физику вовсе не обязательно. Но главная причина снижения скорости не в этом, а во времени переключения головки с одного трека на другой, и чем ближе к центру, тем эта операция производится чаще.
Ну, ок. Но тогда производитель, если рассуждать логически, должен указать в качестве максимальной скорости записи скорость в самой медленной, внутренней зоне. Как никак, это треть диска.
Три зоны только на картинке в википедии, чтобы самые бестолковые могли понять суть )) На самом деле их может быть сколько угодно (зависит от геометрии диска, производителя и т.п.)
производитель, если рассуждать логически, должен указать в качестве максимальной скорости записи скорость в самой медленной, внутренней зоне
Производитель должен одно - получить максимальную прибыль. При этом откровенно не врать. А не договаривать, выдавать максимальную скорость за гарантированную и так далее - ну за это же не бьют, а лохи, которые смотрят рекламу, а не тесты, не переводятся.
Ради интереса пробежался по даташитам нескольких попавшихся под руку хардов - везде дают Max. Sustained Transfer Rate или около того. Ни среднего, ни минимального, ни гарантированного и т.п. - нету. Производитель - он же не идиот. Он, с одной стороны, даст максимальную цифирь (ибо реклама), но, с другой, есть условия, при которых он покажет контролёру это значение (ибо "не врать").
Ну и какое среднее писать, если известно что любой диск со скоростью вращения шпинделя в идеальном механическом состоянии можно затормозить до 480КБ/сек? А потом он стареет и эта скорость уменьшается почти до 0. При том что всегда можно подобрать нагрузку так, чтобы результат был ещё хуже. Что значить средняя скорость, если она зависит от нагрузки?
Коректнее говорить о линейной скорости в начале и количестве iops при случайном доступе. Так производители и не срывают этих характеристик, они есть в даташите.
Уже очень давно диски не показывают ОС свою физическую геометрию, программно адресация идет по LBA-адрес сектора - одно число от нуля и до конца диска. Внутри же количество секторов разное на разном удалении от центра. Но об этом знает только контроллер диска.
Если что, количество зон с разным количеством секторов на трек на современных дисках измеряется десятками.
А в случае с SMR дисками и их ленточками - всё ещё интереснее, и пользователь даже знать не может, куда физически будет записан его яшмовый файл :))
Геометрия уже лет 20 неактуальна. Вся адресация чрез транслятор LBA идёт. Плотность записи на жестких дисках примерно постоянная. Поэтому от внешнего края скорость падает к центру.
А черепичная запись тут совсем непричём. При линейной записи она ведет себя так же, как и CMR. Черепичная проявляет себя, когда надо рандомно писать. Вот там-то помимо записи нужного сектора вычитывается страйп, и записывается обратно с изменениями.
Физическая и логическая геометрии начали разбегаться еще раньше - лет 30 назад. Я писал про физическую геометрию. Логическая геометрия и lba - это из другой оперы.
А черепичная запись тут совсем непричём.
Вот как? А я наоборот, читал статью, где указывалось, что такое поведение - как раз способ вычислить smr диски.
Вот как? А я наоборот, читал статью, где указывалось, что такое поведение - как раз способ вычислить smr диски.
Способ не годится: пост про SMR (TL;DR: последовательная запись всего диска никак не сигнализировала об SMR в ходе записи и, потом, чтения: картинка с чтением).
Но это было в духе волны паники лет 5 назад, тогда многих интересовало как при помощи палки и камня выявить наличие SMR, тогда все диски с большим кэшем на всякий случай записывали в SMR.
Вроде все адекватные способы в посте по ссылке и тут перечислены. Обычно достаточно запроса типа ... filetype:pdf site:seagate.com и знания, что DM-SMR нет среди дисков выше 8 ТБ у Seagate и выше 6 ТБ у WD.
"Я что-то пропустил" - Да. Вы пропустили зонирование.
Спросите в гугле про зоны HDD
Сразу проговорим, почему мы не рассматривали SSD для хранения трафика.
Очень недальновидное решение. Вам нужен тиринг, т.е. разделение уровней хранения. Свежие данные мелкими блоками будут писаться на ssd диски enterprise уровня, которые обеспечивают стабильную скорость записи на всём своём протяжении. Затем более старые данные большими блоками будут переноситься с ssd на raid массив из hdd, где будет обычная линейная запись большими блоками.
В результате вся мелкоблочка будет на ssd, которые лучше для этого предназначены, а на hdd будет запись крупными блоками, причём это будет последовательная запись, где у hdd меньше всего проблем с просадкой скорости.
В их случае тиринг удобнее делать из оперативки, а не через SSD как мне кажется. NAND всегда пишет достаточно большими блоками от 16кБ и выше, для мелких пакетов не очень подходит.
А если поставить достаточно памяти и писать большими блоками на диски из кольцевого буфера - будет вполне себе линейно.
В результате вся мелкоблочка будет на ssd
Из текста статьи:
запись в файлы происходит последовательно блоками по 2 МиБ
А тиринг при плюс-минус равномерном потоке последовательной записи просто бессмысленен - HDD в любом случае либо будет переваривать поток, либо нет.
потом пойдёт запись вместо старых данных - и вот тут ХЗ, возникнет фрагментация или нет (еще и от FS может зависеть).
А если эти данные не только пишут, а еще и читают - то в ситуации "сейчас пишем в начало диска, а вот читаем - в основном с конца" - IOPS сильно упадут...
Если только писать потоком данные как в каком-нибудь видеонаблюдении - то да, HDD или переваривают, или не перереваривают.
При использовании софтверных RAID в Linux с помощью mdadm можно задать принцип записи в RAID. Например, для RAID5 либо RAID6 можно указать чтобы данные на диски писались не всегда сначала на всех дисках, а, например, чтобы часть дисков начинала писать в начало, другая часть в конец, тем самым выравнивая скорость записи по всему объёму массива. ЕМНИП флаг --layout
Ищу способ сделать рейд0 из двух одинаковых дисков чтобы блоки чередовались: нулевой на первом, последний на втором, первый на первом, предпоследний на втором и т.д. Это чтобы скорость в любом месте была приблизительно одинакова. Сохранность не важна.
mdadm --create --verbose /dev/md0 -l 0 -n 2 --layout=f1 /mnt/part0 /mnt/part1
mdadm: layout f1 not understood for raid0.layout не работает.
Максимальная скорость записи в RAID5 и RAID6 достигается при full stripe writes. Т.е. за одну операцию пишутся параллельно на все диски и большой блок данных и его контрольная сумма. Т.е. в каждой операции записи ждём самый медленный диск. Т.е. ваш вариант сделает весь массив таким же медленным , как конец обычного массива.
Как-будто, для этой задачи нужен очень специфичный рейд вида «записывать на быстрый диск два блока, пока на медленный пишется один», чтобы поддерживать среднюю скорость в три блока. Причём со временем соотношение скоростей будет меняться, так что придётся хранить кучу метаданных сверху.
Интересно, существуют ли уже подобные файловые системы .
расследование «заговора» разработчиков HDD
Чего не договаривают производители HDD
Что диски нельзя сушить в микроволновке...
___
Они указывают, что скорость - максимальная. Они рассказывают про уменьшение скорости на внутреннем радиусе. Упоминают на своих сайтах short-stroking*. Картинки из Victoria, HD Tune или AIDA64 в обзорах в интернете можно заметить. Эти же картинки из AIDA64 показывают, что там у SSD после исчерпания SLC-кэша, можно по аналогии задуматься про HDD. Также вопросов не будет, если знать про ухудшение звука у пластинок на внутреннем радиусе. Или про деление дисков любых видов на CLV и CAV (constant linear velocity и constant angular velocity). Или про дефрагментаторы на винде**.
* То есть уменьшение ёмкости HDD, чтобы уменьшить ход блока головок. Это в первую очередь про случайное IO, но линейное тоже растёт (внутренняя часть пластин не используется). В бытовом варианте можно место за первым разделом не выкидывать, а класть туда менее горячие данные.
** Прикольная оптимизация, продвинутую дефрагментацию объявляли ненужной скорее по принципу "нет на Linux - значит не нужно (а если появится, то станет нужно)".
Linux это не ОС, интересно как бы были теже тесты именно на ОС, с настроенной конкретностью как это должно быть для СХД, потомучто порой есть отличия как не крути. может дело в какихто тонкостях помимо ЖДшек, может есть то как конфигурируют на ОС определенные нюансы, может есть + к ЖД наблюдениям какие-то подходы, реализация ZFS на линукс ок, вот я например не пользуюсь на ПК ZFS/btrfs на линукс, пользуюсь ext4, но я не сервер и мне этого достаточно, а вот на ФриБСД пускай и ПК ZFS, на Соляре соотв их фс и вот так по крупицам приходят нюансы, а просто ЖД наблюдать ок, вопрос достаточно критичный Линукс тогда должен поддерживаться, поддержка должна быть, летать по форумам? по таким вопросам, потом далее, никаких роллинг дистрибутивов и вот уже отпадает большая часть линуксов и становится понятен вопрос, потомучто помимо обновления нужна поддержка и это критический вопрос, которого может не быть просто у линукса
и репозитории могут не помоч в поддержке, хотя безусловно удобно, но когда линукс поставляется так как сейчас, и разделен на части это проблема
еще как вариант, что можно добавить, есть сессия, помимо виртуализации, кластеров и прочего, можно подумать как делать так чтобы траффик квантовался(предположение, самоделился и самособирался или долинковывал куски ) на нужное количество ниток в зависимости от его длинны, и писался в 1 хранилище при отключении соединения или писался частями, видимо да моментов много в этом деле, часть этой реализации у вас есть, у вас есть контейнер, и во время сессии пишется контейнер, а контейнер можно делить и писать частями или предзаписывать частями, тоесть он может передаваться последовательно по 1 на сессию, а может не по 1 а нескольким ниткам на сессию, если это критичное что-то, например балансировка записи на диск посредством софта(это всё предположение и сравнение с одной утилитой)
возможно какието ОС или решения Ентерпрайз уже учитывают это, а может это невозможно но наверняка есть какието тонкости с большим размером обьема данных и запись на них, тоесть 100 терабайт(1 для всех а значит это условия для баланса, а может нет, интересно как это професионалами решается )), и прочее
Какие замечательные люди работают в Positive Technologies. Можно быть уверенным, что их продукты созданы исключительными профессионалами в своей области. Автор, пишите еще о своих чудных открытиях, мы будем ждать с нетерпением. А так же мотивируйте коллег поделиться жизненным опытом, у них наверняка есть что рассказать.
Следующим открытием будет черепичная запись и ее влияние на скорость диска?
Кто не застал, можете ещё про CLV и CAV у оптических дисков почитать, не так уже актуально, но тоже любопытно может быть )
Странное ощущение возникло к концу прочтения статьи, но когда прочитал первые же комментарии - успокоился. И да, нет никакого заговора.
И теоретическая скорость записи в этот массив должна достигать 255 MБ/с × 6, то есть приблизительно 1,5 ГБ/с.
У товарищей явные проблемы с теорией о RAID6.
Поёрничать...
Ждём статью: "Мы использовали в проекте RAMdisk - но после перезапуска сервера данные там терялись, вы не поверите, но...." :)
Это что, ждём статью про то что ЭЛТ мониторы быстрее, контрастностнее, любых современных LCD или OLED
название статьи "чего не договаривают производители оперативной памяти"
Мы воспользовались mc для просмотра файлов и увидели, что у нас все файлы в двух копиях (левой и правой). Одну из копий мы решили удалить, но оказалось, что создатели mc не договаривают одну очень важную вещь.
Кто помнит влияние параметра "Interleave" при форматировании жесткого диска на скорость чтения?
Помним. Можно сильно затормозить диск не правильно выбрав. Нам подарили ITT XTRA XP c Miniscribe HDD на 20 МБ - переформатировал его со значением 7. Потом проверил с Calibrate (часть Norton Utilities) - оказывается оптимальное значение 4 - пришлось опять форматировать. А школе устанавливали контролёр и диск от Seagate - там оптимальное было 3 сектора. Потом ещё раз видел очень интересную картину с мягким диском - с 1700.com отформатировать с другим Interleave и скорость записи/чтения с него сильно, как мне показалось, выросла (Но это было в один раз у друзей (или в школе?) больше не встречал - возможно было не правдой).
С флоппами работало не со всеми: например TEAC ускорялся, а Samsung нет.
Ну и дискеты отформатированные на повышеную ёмкость далеко не всегда читались в других дисководах.
Мы в своей компании тогда решили проблему так: пошли все вместо на рынок и продали свои дисководы. И купили пять новых TEACов.
Потом ещё раз видел очень интересную картину с мягким диском - с 1700.com отформатировать с другим Interleave и скорость записи/чтения с него сильно, как мне показалось, выросла (Но это было в один раз у друзей (или в школе?) больше не встречал - возможно было не правдой).
На флопиках был важен еще один параметр - sector shift, когда сектора на каждой следующей дорожке сдвигались относительно предыдущих на 1-2-3-... сектора, и при последовательном чтении, пока головка ехала с одной дорожки до другой, под нее как раз успевал подъехать первый сектор следующей дорожки. И это было слышно невооруженным ухом, вместо тук----тук----тук дисковод издавал тук-тук-тук ;)
interleave, насколько я помню, по определению замедлял чтение - требовалось 2(3) оборота вместо одного, и был нужен только при максимально плотной записи, когда промежутки между секторами становились настолько маленькими, что контроллер не успевал передать содержимое одного сектора до начала следующего. Тогда приходилось форматировать с чередованием, было медленнее, но вместо 1.6 МБ на дискету можно было 1.8 утоптать ;)
Дикие времена были...
Ух, какие вы молодцы! Профессионалы.
Успехов вам в нелегком деле уничтожения рунета.
Подскажите, немного не в теме: вроде как изобретали перпендикулярную запись, где дорожки располагаются по радиусу диска, она вроде не должна давать описанный эффект. Отказались от этой технологии?
В перпендикулярной записи дорожки располагаются аналогично старому варианту. Разница только в ориентации магнитных частиц. И классические жёсткие диски сейчас (если не вспоминать черепичную запись) - именно с перпендикулярной записью.
если не вспоминать черепичную запись
После продольной записи (LMR) все диски - с перпендикулярной (PMR), эти тоже.
PMR пытались использовать в значении "без SMR", но это только путаницу создаёт, для "точно без SMR" придумали название conventional magnetic recording (CMR).
Из-за представления, будто все эти технологии исключают друг-друга, ещё одна ошибка встречается: что HAMR-диски не могут быть с SMR.
Можно как 3 оси представить:
LMR / PMR - ориентация магнитных доменов
CMR / SMR - расстояние между дорожками
∅ / ePMR / HAMR / MAMR - наличие доп. источника энергии
"Зумеры открыли, как работают HDD" - так наверное стоило назвать :)
У современных жестких дисков есть "медиакеш" - выделенный кеш записи в самой скоростной части диска, откуда данные на фоне перемещаются в более медленные зоны.
Аналогично работают SSD (SLC-кеш) и медиакеш SMR дисков. В отличие от последних, падение скорости на CMR-дисках будет не таким драматичным.
Если честно не понимаю почему столько желчи в комментариях. Неужели комментаторы действительно думают, что все должны знать весь пласт знаний человечества? В том числе в областях, которые не являются непосредственно твоей специализацией? Лично я о таком факте не знал. Спасибо авторам, теперь знаю.
Так уже писали:
Собственно, будь заголовок менее кликбейтным и будь пояснение о том, что тут не ставится целью срывать покровы с мирового заговора производителей дисков, но показать, как важно правильно проектировать хранилище - и реакция была бы другой.
комментаторы действительно думают, что все должны знать весь пласт знаний человечества? В том числе в областях, которые не являются непосредственно твоей специализацией?
Комментаторы думают, что если компания более 10 лет пилит коммерческий продукт, основной функцией которого является высокоскоростная запись на диски, то она обязана иметь специалиста, который знает, как устроены эти диски. Благо, конкретно те знания, которые они нам, аки Прометей с Олимпа, преподносят в этой статье, есть на соответствующей странице Википедии.
Комментаторы считают, что если человек берет деньги за свою работу - он должен разбираться в том, что делает. Для тех, кто берет деньги за то, в чем не разбирается, есть специальное название - шарлатаны.
Комментаторам не нравится, когда продающийся за немалые деньги (часто бюджетные) продукт разрабатывают люди, не являющиеся профессионалами в этой области. Комментаторам не нравится поучительный тон и провокационный посыл статьи, когда совершенно открыто декларируемые технические особенности выдают за обман.
Вы что-то перепутали. "Основной функцией" запись на диски является у СХД или рейд-контроллеров, а у обсуждаемого продукта она совершенно иная.
Ок, одной из ключевых функций. Без которой весь остальной продукт работать не будет.
И в этом продукте с этой функцией что-то не так? Если да - что именно?
а у них на самом деле хранение - это функция продукта? Или у них функциональность "захватить трафик и записать в /var/sniffer, а потом записанное прочитать и проанализировать"?
Если второе, то у них должна быть информация о характере IO нагрузки на этот /var/sniffer, в которой линейная скорость записи - лишь "одно из" свойств, и не самое главное, потому что кроме авторов писалки в /var/sniffer и читалки для DPI из неё - никто лучше не сможет этот характер нагрузки описать. А уже под эти требования подбирается система хранения.
Но в публичном доступе то ли нет, то ли не нашел информации. Только схемы включения для перехвата трафика.
Я вот одного не понимаю - вот есть софт, в нëм указаны требования к железу. Всë - дальше не должна быть забота разработчика. Вот эти все разборки должен был делать интегратор, который внедряет систему, который по требованиям подбирает оборудование, собирает нужный конфиг (нужный тип рейда, нужную ОС, более подходящую ФС и т.д.).
А то получается, заказчик закупил железо, понадеявшись на маркетинговые цифры скорости записи дисков, но не протестировал должным образом. Достаточно было разок викторией прочитать один диск, и разок так же прочитать готовый рейд. Можно и не викторией, а тем же dd, тут это будет то же самое. Сразу было бы понимание, что такая конфигурация не подойдëт для этого софта.
В качестве решения со стороны разработчиков можно будет продумать вариант с требованием отдельного устройства (ssd) в качестве кэша на время таких просадок, и добавить встроенные тесты производительности, чтобы это было выявлено уже сразу после установки (или даже во время установки это делать, с соответствующим предупреждением, что производительность недостаточная).
Вот эти все разборки должен был делать интегратор, который внедряет систему
То есть вы предлагаете запретить заказчику самому себе внедрять подобные системы?
А не, хуже - вы предлагаете обуславливать приобретение одного продукта (PT NAD в данном случае) приобретением другого продукта (услуг интегратора)? Для потребителей такое так прямо законом запрещено, для организаций нет, но в общем-то это называется "навязыванием дополнительных платных работ и/или услуг".
Так-то да, интегратор должен был бы это учесть, если бы он был.
Достаточно было разок викторией прочитать один диск
В общем случае - недостаточно. Этого достаточно, только если операции с диском идут в один поток. В остальных случаях уже надо имитировать нагрузку в соответствующее количество потоков и с соответствующими процентами операций чтений и записи.
В остальных случаях возникает ситуация "IOPSы важнее линейной скорости". В частности, количество дисков в массиве при том же конечном объеме массива важнее объёма дисков. Например, 10 дисков по 1ТБ для 10ТБ массива RAID0 будут быстрее и 2 дисков по 5ТБ, и 1 диска на 10ТБ.
И по идее вендор бы должен дать рекомендации по требованиям к дисковой системе (количество IOPS, процент IOPS разных типов - в зависимости от скорости записываемого трафика)
разок так же прочитать готовый рейд
И столкнуться с ситуацией "деньги-то потратили, а не подходит"?
Это всё надо учитывать до набивания хранилки дисками...
продумать вариант с требованием отдельного устройства (ssd) в качестве кэша
Это всё уже детали, которые подбираются под характер нагрузки :) Можно и без SSD - иногда просто в два-три раза больше дисков меньшего размера для того же объёма данных достаточно поставить, например.
Я с телефона сейчас, так что извините, детально цитировать не буду.
Не запрещал я ничего и никому, я просто сказал, что этими выяснениями у клиента не разработчик должен был заниматься. Нет денег на интегратора - пожалуйста, занимайтесь сами всеми тестами, закупайте и возвращайте диски и т.д. Но именно для этого и подключают интеграторов - чтобы они всë это сделали, чтобы взаимодействовали с разработчиками и т.д. Как правило, у таких компаний есть нужные специалисты с опытом в подборе и эксплуатации железа, они могут грамотно построить тесты, и потратить десяток дисков на тесты для них - вообще не проблема, клиенту даже не придётся думать о возврате дисков, если они недостаточно производительные.
Про "разок викторией" я конечно слишком утрированно сказал. Конечно лучше более приближенные к реальности тесты.
Окей, я тоже утрировал в ответе. Не, формально я всё правильно сказал про навязывание услуг, кстати. Но могло бы и не выглядеть как заготовка для претензии, необходимой перед иском в арбитражный суд )
На счёт "темы виктории". Начнём с главного - это не делается "методом научного тыка".
Есть методики расчёта дисковых массивов под нагрузку. В которых, как уже говорил, на первом месте не линейная скорость, а IOPS - потому то линейная скорость почти никакой информации о диске не несёт (даже для SSD). "Где-то потом", исходя из характера нагрузки можно подобрать диски так, чтобы массив обеспечивал нужную линейную скорость с некоторым запасом на случай флуктуаций нагрузки, с допустимым latency и прочим.
А вот уже после расчёта можно и тестовый стенд собирать...
вот есть софт, в нëм указаны требования к железу. Всë - дальше не должна быть забота разработчика
Чтобы правильно сформулировать требования к железу, надо понимать, как оно работает. А разработчики не могут, потому что не понимают. И получается, что есть железо, которое соответствует требованиям, сформулированным разработчиками, но при этом фактически непригодное для их программы.
Вот именно, что железо не соответствует. Тот, кто решил, что оно соответствует - просто доверился маркетинговым цифрам скоростей hdd, но не протестировал, какая она будет в реальности. Это примерно то же, что принимать внимание частоту процессора в каком-нибудь турбо режиме и рассчитывать что она всегда такая будет.
И с точки зрения закона, и с чисто человеческой, заказчик не обязан ничего тестировать, потому что он покупает готовый продукт с заявленными характеристиками, а не сырой полуфабрикат. Он обязан свериться только со спецификацией железа, предоставляемой производителем. В требованиях написано: максимальная скорость записи такая-то, значит, заказчик должен лишь убедится, что заявляемая производителем дисков максимальная скорость записи не ниже. Почему разработчик в требованиях заявил именно максимальную скорость записи, а не гарантированную- это вопрос именно к разработчику и к его неспособности корректно сформулировать системные требования.
Во если бы разработчик заявил, что требуется определенная гарантированная скорость записи при заполнении на 90%, тогда можно было бы говорить о каком-то несоответствии.
. В требованиях написано: максимальная скорость записи такая-то, значит, заказчик должен лишь убедится, что заявляемая производителем дисков максимальная скорость записи не ниже.
Максимальная скорость прописана - это скорость в смысле с которой софт пишет?
Тогда
лишь убедится, что заявляемая производителем дисков максимальная скорость записи не ниже
логическая ошибка. Должно быть "минимальная скорость записи диска не ниже". Тут в том и проблема, что производители дисков не указывают эту минимальную скорость (им это просто невыгодно, нужно максимально большие цифры показывать, а кто там примечания читать будет).
Тут в том и проблема, что производители дисков не указывают эту минимальную скорость
Потому что её слегка не существует. Ну или она около нуля - если от души насыпать random iops :)
А они таки будут, потому что по идее там должно быть как минимум два потока - один пишет (а то может даже и два пишут, при схеме захвата с двух карт), и как минимум один читает записанное для анализа.
Почему разработчик в требованиях заявил именно максимальную скорость записи, а не гарантированную
Это-то как раз понятно ) Потому что последней не существует.
Но есть более интересный вопрос - а что заявил производитель в системных требованиях вообще?
Или заказчик просто взял максимальную скорость записываемого потока (условно, 1Gbps, если захват с одной сетевой карты, или 2Gbps, если захват идёт в два потока с двух сетевух - одна для трафика в одном направлении, другая - для трафика в обратном направлении), взял скорость диска, и решил, что её достаточно? Линейная скорость диска вообще мало что говорит о диске.
Вот берём диск, пишем на него поток числом 1 штука... Видим скорость, как на графиках Виктории. А потом одновременно с потоком на запись пытаемся еще и читать с него для анализа записанного трафика (ради чего эта система и стоит вообще - анализировать трафик и искать в нём угрозы, а не косплеить "Призму Яровой"). И оппа - скорость обеих операций валится в разы. А если там еще и файлики растут по мере записи в них - то скорости валятся еще больше, потому что дополнительные операции записи метаданных файловой системы возникают.
Почему разработчик в требованиях заявил именно максимальную скорость записи, а не гарантированную- это вопрос именно к разработчику и к его неспособности корректно сформулировать системные требования.
Таки нашел мануал по PT NAD. И там всё очень забавно... Далее цитаты оттуда:
Для захвата трафика со скоростью до 200 Мбит/с рекомендуется использовать массив RAID 1, для более высоких скоростей — RAID 6 или RAID 10.
Ну RAID1 понятно, 20МБ/с нынче любой диск выдержит при однопоточных операциях, даже с накладными расходами из-за зеркала. RAID10 тоже понятно - это самый быстрый из рейдов с избыточностью, ценой половины дисков. А вот RAID6 c его самым большими накладными расходами почему туда записали?
И для хранения трафика (не метаданных - для метаданных всегда рекомендуют SSD) рекомендуют HDD. Например для "200 Мбит/с — 1 Гбит/с".:
Жесткие диски для хранения PCAP-файлов
Объем
13 ТБ
Скорость записи
125 МБ/с
Вот только это - всё! Где IO block size, где процент read IO rate, рекомендации по тюнингу FS? (может не нашел и оно где-то в другом месте?)
А то ж там по калькулятору (не у вендора PT NAD :) - у него только расчёт общего дискового пространства есть) "чудеса" бывают... На 20 дисках 90% write rate блоком в 128 К в RAID10 даёт скорость записи от 103 до 137 МБ/s (на 20, Карл! и калькулятору вообще наплевать, что там вендор диска говорит про его линейную скорость, кстати). А вот с мегабайтным блоком - раз в 8 больше. Для первого блока калькулятор говорит, что надо дисков 26, а для второго хватит и 6. А в RAID60 для второго блока надо 8 дисков.
Но это мы чисто производительность хранилища посмотрели, без накладных расходов от файловой системы. А она можешь съесть какое-то количество IOPS (в зависимости от типа и тюнинга), следовательно, скорость снизится, и надо будет ставить больше дисков.
Но если бы разработчик заявил, что требуется определенная гарантированная скорость записи
Хотеть несуществующего можно вечно ;) Это ж не труба с непрерывным потоком воды, а система массового обслуживания. Добился от неё нужного IOPS (скорости обработки заявок) при заданных block size и read/write rate - получил нужную скорость, не добился - не получил.
Очередь в кассу движется со скоростью сканирования кассиром покупок, которая такая, какая есть, а пересчёт этого в человеков в час и времени ожидания в очереди (latency), которых все так хотят видеть - первого побольше (с т.з. магазина), второго поменьше (с т.з. покупателя - обычно не совпадает с т.з. магазина, кстати), зависит от количества покупок в тележках у человеков (в идеальном случае, исключаем взвешивания, возвраты по кассе и прочие моменты, пренебрегаем движением ленты и выбиванием чеков). Нечто похожее и с дисками.
p.s. найденный калькулятор может не с самыми свежими типовыми параметрами дисков оперирует по умолчанию (2019-го года вроде), но для того, чтобы в исходной задаче заказчика задуматься "а точно хватит двух дисков" и "а что еще надо узнать для проектирования хранилки, кроме линейной скорости дисков" (и "не спросить ли это у вендора ИС, не самим же догадываться") - его достаточно :)
p.p.s. да, вендор именно гарантированную скорость и попросил... только не дал информации, необходимой для расчёта системы, её обеспечивающей ;) а так да, хотеть несуществующего можно вечно - скорость величина расчётная (и контролируемая экспериментально), а не табличная в характеристиках диска, и меняется в зависимости от характеристик нагрузки на диск.
Самое забавное, что российские государственные и окологосударственные разработчики сплошь и рядом делают продукт, который работает только в их "тепличных" условиях. Иногда ещё и ссылки и логины со своих компьютеров выкладывают в свободный доступ. Профессионалы, чо.
Скорее это как измерять производительность процессора исключительно частотой. Процессоры разных поколений при равной частоте и тех же задачах - по производительности могут очень заметно отличаться )
В случае диска - скорость в байтах в секунду о нём мало что говорит вообще, потому что это система массового обслуживания (с очередями, как положено), и обслуживает она не потоки байт, а операции ввода-вывода. Почему IOPS (input/output operations per second) и считается более важной характеристикой хранилищ, чем линейные скорости.
автор меняйте диски или пробуйте на вашем рейде 6 запускать trim для дисков.
да, trim такой же как на ssd но для smr hdd
Гениальная статья.
Чтобы всё как часы работало, нагрузка не должна превышать 30 процентов и в данном случае от 133 мб/с, т.е. 40 мб/с на диск.
Порог превышен в 4 раза, надежность такой системы близка к нулю.
Это для критических данных, а мусор можно писать и с пропусками.
Ого, выявлена разница между угловой и линейной скоростями! Круто.
Я постоянно вижу что высасывая кинцо по проводу с домашнего ПК с HDD на минипк у телека - скорость чтения скачет от 250мб/с и менее - в зависимости от того где конкретно размещен файл.
Ну да - строить систему , критичную к скорости записи без двух-трёх крастного запаса по спекам - странное решение.
В конце концов, если диски уже закуплены, можно использовать только внешние цилиндры. Правда объем уменьшится где то на треть.
Во времена Windows XP постоянно включали дефрпгментацию, чтобы выжать ещё скорости из системы. Вроде как в процессе дефрпгментации (возможно только в модных сторонних программах) файлы переносили ближе к началу диска...
".., дампы заполняют 90% предоставленного места, а затем начинается процесс ротации..." - официально не рекомендуют заполнять диск с ZFS более чем на 80%.
Почитал и вспомнил спор с менеджментом где-то в начале 2010-х, то есть 10+ лет назад.
А разговор был о том, что SIEM система не успевает писать тот поток данных что хотелось бы. Не буду вдаваться в подробности, но всё упиралось... та-дам! в скорость записи массива дисков RAID5 (с шилдиком EMC2). Просили денег на SSD, но тогда денег не дали, было слишком дорого, так как надо было менять собсно сторедж, а наш тим был слишком маленький в масштабах компании чтобы под нас делали план апгрейда. Проблема решилась сама собой через 3 года: во первых вендор SIEM сменил движок БД на более производительный noSQL, а во вторых, сторедж обновили на SSD, ага, у которых стоимость больше и сменили на RAID60, всё. Проблема бутылочного горлышка ушла.
То есть просто найдите денег на SSD.
Хьюстон, у нас проблема, или Чего не договаривают производители HDD