Комментарии 270
Но при этом «налить» надо больше кэша — что-бы диск начал «тупить»?
А как к подобному отнесутся софтовые mdadm, ZFS и прочие? У них нет более тонких настроек для имеющихся дисков? Ведь они как-то различают HDD и SSD, например? Иначе-бы при наличии SSD все HDD диски периодически отваливались как «неисправные»…
Ну и для всяких WAFL это по-боку, вроде, должно быть? Они всегда пишут в чистую область, а уже потом «разгребают» данные, в моменты простоя?..
PS: В ЖЖ подробностей больше — возможно, стоит скопипастить часть в статью или, как минимум, хотя-бы дать ссылки на статьи в ЖЖ.
Я так понял, что диск не просто тупит, а выкидывает ошибку. Всё это очень похоже на сырость прошивки.
Железный или программный контроллер не могут разобраться почему действие выполняется очень долго, и предполагают, что диск умирает. Они могли бы справиться с этим, если бы диск сообщал, что у него —
Разгрести данные опосля будет тяжело, ибо будет выполняться ну очень долго. И опять же, диск должен сообщить, что у него такая беда, а ФС и ОС должны суметь сделать вот это всё. И, как обычно, если железо/софт сняты с поддержки, то кто и как эти новые способности будет добавлять?
Опять же, диск будет постоянно дёргать головами и писать-переписывать, а значит, время жизни будет сокращаться. И в это время он будет неспособен на свою обычную работу.
Как-то не стоит это всё +25% ёмкости, ПМСМ.
3dnews.ru/1008543
3dnews.ru/1008687
А как к подобному отнесутся софтовые mdadm, ZFS и прочие?
Я не тестил SMR диски в ZFS, но интересовался этим и цитировал источники еще несколько лет назад. в ZFS очень существенно замедляется работа. Как видно из цитат в этом посте — до отвала по IDNF (sector ID not found)
Ведь они как-то различают HDD и SSD, например? Иначе-бы при наличии SSD все HDD диски периодически отваливались как «неисправные»…
КМК только если SSD уж совсем колом станет :) По опыту ZFS полагается на установленные у диска таймауты в попытке записать в него сектор (TLER и около него)/ Один диск будет тупить и пытаться что-то записать долго-долго, другой выкинет почти сразу.
В LJ подробностей больше-я попытался написать как можно более не-эмоциональный пост на хабре. Все же он тут первый — но отрицательную карму почему то уже имею :) (не знаю только где посмотреть сколько — но пустило только в Recovery Mode). И то написал только потому, что читатели сильно посоветовали — глядишь, народ уберегу от неудачных покупок.
Также непонятен смысл новости. Хорошая новость или плохая новость хоть?
Описание от Seagate
Shingled magnetic recording
thg.ru — журнашлюхи, в т.ч. дающие рекламу сайтов с MS виндой и офисом по 10$.
Черепичная запись даёт +25% ёмкости при падении случайной записи до примерно нуля. Производители ЖД устроили олигополию и оборзели. На SMR будут переводиться все ЖД — ибо +25% ёмкости, а на остальное — насрать.
Получается такая вот борьба с торрентами.
Один из выходов — использовать F2FS и подобные ФС (приспособленные для флэша и т.д.). Однако в openSUSE/SLE F2FS по умолчанию запрещена, ибо ненадёжна пока что.
ФС с COW похоже что лучше не использовать с SMR, т.е. яблочная APFS и виндовая ReFS тоже в пролёте.
А можно прояснить мысль про борьбу с торрентами? Это, в смысле, если торренты качать на рейд-массив из этих дисков (т.е., писать кучу мелких блоков), то они отказывают и таким образом вред торрентам?
т.е. яблочная APFS и виндовая ReFS тоже в пролёте.
яблочники скорее всего могут позволить себе ставить в imac отдельные серии накопителей, где не будет проблем. Либо SSD.
Если хотите мое объяснение
От Сигейта на Хабре
От NIX
пустило только в Recovery Mode — написал только потому, что читатели сильно посоветовали1) эти читатели считают Хабр лучшим ресурсом по HDD?
2) когда не пускало
а) Ваша местная карма была отрицательной?
б) это не послужило Вам никаким «знАком»?
3) теперь, спустя несколько дней — Вы удовлетворены?
4) что еще я забыл спросить? (с)
5) спасибо за статью!
2а — да, -1. Не знаю уж за что — это моя первая публикация, минусовых комментов тоже не было.
2б — не-а :) мнение одного анонима — это точно не знак, это шум
3 — я даже удивлен. Приятно удивлен — ожидал более агрессивной реакции. Впрочем, 7 минусов набралось, так то все в целом нормально :)
4 — про здоровье — спасибо, хорошо. Надеюсь, как и у Вас ;)
5 — приятно быть хоть чуточку полезным людям
приятно быть хоть чуточку полезным людямно людя неблагодарны: если писать редко и мало — будешь виноват в недонесении (и даже утаивании) важной инфы, а если много — то алармистом обзывают и минусуют.
И тут приходится каждому самому решать :(
Еще раз спасибо и успехов всяческих — не только здоровья, а и ваще!
Как я понимаю, для железного RAID-контроллёра есть повод пометить диск как неисправный, пока тот «тупит» раскладывая как надо то, что ему «налили»?.
Да, и это вполне нормальное поведение контроллера. Нефиг щёлкать клювом в RAID-е. Не успел ответить за отведенное время — извини, накопитель, но семеро одного не ждут. В лучшем случае ты тормозишь, в худшем — ты сыпешься, поэтому проще тебя заранее заменить от греха подальше.
"СМИ" как обычно с запозданием в 2-3 недели: Beware of SMR drives in PMR clothing (30 марта, о проблемах в рейде ZFS)
А то может пора «нормальными» двушками закупаться, пока их из продажи не вывели. Они у меня в RAID6 на mdadm в домашнем NASе…
А насчет закупаться — все помним, как быстро вендоры перешли на AF диски. Может и сейчас так будет. Но, надеюсь, как и прошлый раз довольно долго при желании можно будет найти. Так что впрок я б не закупался. А вот если прям сейчас надо — то да. Станут CMR диски редкостью — подорожают точно.
разный цвет у дисков WD может соответствовать одинаковому железу при разной (и то не обязательно) прошивке
В зависимости от серии. Какие-то действительно одинаковые вплоть до прошивки, отличаются только активным пресетом (в интернетах можно найти утилиту, которая меняет в ней флаги), какие-то разные. Мне вот домашний Blue на 4ТБ попался такой, который можно перещёлкнуть флагами на Purple. Я частично это и сделал, чтобы он перестал постоянно парковать головы, и вообще поменьше тормозил.
Маркетинговый мухлёж, в общем.
WD Blue WD20EZAZ у которых 256 кеша, в отличие от WD Blue WD20EZRZ с 64. Цена одинаковая
Кроме кеша, у них существенно отличается вес. Так что да — у WD20EZAZ SMR
В зарубежных источниках упоминается, что на SMR перешли диски 2-6ТБ, 8 и далее, который были non-SMR, такого пополнения в модельном ряду не получили.
Упс, поправлю себя, в зарубежном thg, на который есть ссылка, этот момент как раз упоминается.
Все три производителя начали продажи...
так вот как выглядит невидимая рука рынка…
Первое, они не заявляли что там нет SMR.
Второе, диски данных серий явно не предназначены для работы ZFS или RAID5/6, это домашние, максимум малый бизнес. Тем более не для непрерывной нагрузки в 100Мб/c.
То пора скупать WD100EMAZ.
Я-то наделся пару 32GB Unbuffered ECC взять…
Если человек пытается в машину, изображающую сервер (домашний, не домашний, не суть важно), воткнуть условный Toshiba P300, предназначенные для десктопа, он заведомо ССЗБ.
Но на одном — двух серверах это задача с не предсказуемым финансовым эффектом.
Цитата прямо из статьи
WD RED — WD Red EFAX — SMR диски и имеют 256 Мб кеша. Диски EFRX — не используют SMR (это обычные CMR диски) и имеют кэш 64 Мб
Или WD Red уже не для NAS?
Интересно, если производители NAS не включат диски в совместимые или даже начнут предупреждать о несовместимости, чтобы к ним не было претензий.
Именно. И в них — smr. Без smr теперь WD Red Pro, но надолго ли?
Суть в том, что кроиловом не пользователь начал заниматься. А пользователь страдает из-за кроилова компании и использования ею dark paterns.
домашние диски для не домашних задач
Во-первых, граница домашний/недомашний больше существует в умах маркетологов.
Во-вторых, 20 ТБ, которые гелий и smr, делаются явно не для дома.
В-третьих, NAS это уже сервер.
В четвертых, прочитайте уже источники — как раз в одомашенных NAS и выяснились проблемы с этими дисками.
Но raid5/6 и 100мб/сек на запись в течении 40мин( а это 240гб ) явно не относится к классу задач домашнего nas.
Задача производителя тут попросту указать, что после трех минут интенсивной работы производительность деградирует. От сих — и до сих. Процессоры троттлят, это в спецификациях указано, и никто пока от такого указания не умер.
А дальше дело клиента решить, что ему больше надо: емкость, цена, стабильная работа или шашечки.
они не заявляли что там нет SMR
Производитель, который уважает своего покупателя, обязан указать такую информацию. Лично я не хотел бы смотреть на «качели» на графике записи данных в своём ПК. Производитель банально ухудшил скоростные характеристики для конечного пользователя ценой экономии на пластинах для себя. Если будут указывать — диски не будут пользоваться популярностью. Касательно статьи — лично я уже достаточно давно видел информацию, что производители не указывают в даташитах наличие SMR, просто раньше это больше касалось HDD категории 4Тб+
диски данных серий явно не предназначены для работы ZFS
Да, а еще они не предназначены для работы ext4 и btrfs. С каких пор производитель решает, какой ФС мне пользоваться на домашнем ПК? Кроме того, ни на сайте производителя, ни в даташитах я никогда не видел рекомендаций или запретов к использованию той либо иной ФС.
С каких пор производитель решает, какой ФС мне пользоваться на домашнем ПК?
Это таки не повод вкорячить ZFS, которой для нормальной работы нужно выделить десятки гигабайт памяти, на домашний ПК (а не на сервер или рабочую станцию хотя бы). У человека должен быть здравый смысл.
Как я написал комментарием выше, поговорку «кроилово ведет к попадалову» придумали не зря, попытка собрать домашний сервер из говна и палок приведёт именно к говну и палкам.
Вы о ZFS кроме мифов ничего не знаете.
ext4 и btrfs
?
ZFS, которой для нормальной работы нужно выделить десятки гигабайт памятиZFS легко настраивается для работы на лэптопе о 768 МБ ОЗУ, зачем вы пугаете народ?
собрать домашний сервер из говна и палок… и при этом надежно хранить на нем данные — как раз то, за что любят ZFS.
ZFS легко настраивается для работы на лэптопе о 768 МБ ОЗУИменно. Пятый год пошел как сестре настроил мини NAS для дома — Odroid C1 (ARM с гигабайтом памяти). Внешний USB диск в ZFS — тк пользователи обслуживанием NAS в принципе не будут заниматься по уровню компьютерной грамотности. Через год поднял на нем во FreeBSD Jail торрентмонитор. Все годы полет нормальный — качает, раздает дома видео, служит файлопомойкой.
Снова заинтересованно смотрит на Lamobo-R1 (Banana-Pi с sata, 802.11n, и ethernet switch).
Все равно без дела валяется.
Freebsd 12 и Bananian работали неплохо, но, кажется, фряха не видела сеть от слова совсем, а банан потерял возможность конфигурировать свитч с переходом на свежее ядро.
А еще придется потыкать ее паяльником, потому что от жесткого диска на ней перегревается линейник в питании этого самого диска… Хотя, это WD Black7500 кушал как не в себя, а с мелким сигейтом, может, и нормально все будет.
Подождите, я правильно понимаю, что производитель не указывает эту инфу? Ну таким образом я покупаю кота в мешке?
Sure.
Хотя, с год назад каджиту попались один или два диска, на которых явно было указано shingled, но в основной массе эта информация не указывается даже в спеках, что порождает немало спекуляций.
Как бы мне гарантированно найти не-SMR диск? Пока для себя решил, что надо будет прочесать все форумы, в первую очередь англоязычные.
Я бы взял и SMR, но под другие цели (архив). А в существующий массив — однозначно нет!
Сильно зависит от сочетания ваших потребностей, возможностей и готовности рисковать.
Надежнее всего проверять форумы и заказывать там, где согласны на манибэк без объяснения причин.
Этот рискнул, взял себе WD Elements Desktop 10TB по скромной (16к, сейчас — 18к) цене и распотрошил. Восьмерка тоже должна быть нормальной, 12 и 14, а так же все, что меньше — надо гуглить, в мелких встречался полный светофор (зеленые, синие, красные), крупные могут оказать smr-версиями тех же white label hba.
Extremis malis extrema remedia.
в существующий массив
Посмотрите какие у вас там диски и изучите доступность таких же. Не обращайте внимание на маркетинговые имена (RED, Barracuda, IronWolf). Смотрите на длинные буквенно-цифровые названия моделей.
Например, если стоят WD RED EFRX — такие же можно и взять. А EFAX — не стоит.
диски данных серий явно не предназначены для работы ZFS или RAID5/6
Исходно речь зашла о WD RED. Согласно маркетинговому сообщению — Designed and Optimized for NAS Compatibility. И именно для RAID и вылезает проблема — не важно программного, аппаратного. Алан Браун, кстати, наткнулся на проблему с своем домашнем NAS Synology — если это не NAS, то…
не предназначены
На SMR диски хорошо ложится только один вид нагрузки: записывать огромными кусками от забора и до обеда.
Естественно, ни одна нормальная ФС, кроме ISO 9660 (cdfs) так себя не ведет и ни у одного домашнего юзера нет и не может быть подобных сценариев.
Поэтому внедрение SMR необходимо скрывать — иначе не продашь.
А могла бы быть отдельная линейка дисков для сверххолодных данных.
и ни у одного домашнего юзера нет и не может быть подобных сценариеабсолютно обычный сценарий для файлопомойки и кинчиков
И ладно, если это не основной диск, но файлообменики достаточно активно пишут и читают, а если и диск заполнен на половину и фрагментирован — уже страшно.
Огромный — это размером с черепичный блок, n смежных дорожек, который, судя по кэшу, ближе к полусотне мегабайт. И еще его размер плавает — геометрия. При этом никакой случайной записи, вроде обновления индексов, таблиц аллокации, mft-records/inodes, обновления меток времени, журналов и даже банального fsync — быть не должно.
Так что нет у юзеров таких задач. У бэкапного хоронилища — есть, а у юзеров нет.
Потому что ни одна ФС общего назначения так не работает. А значит — сборка мусора, перемещение данных и прочие прелести ssd. Только IOPS на три порядка меньше. И случайная запись в 0,5÷1,5 МБ/с, характерная для PMR-дисков превращается…
У каджита прямо вот, под руками, лежит такой. ST2000LM007-1R. Усыпанная бэдами 320-ка от гнусмаса — шевелится быстрее.
Пфе! У каджита скорость копирования с nvme на usb2-флешку — 2ГБ/с.
Этот думает, вас ждет масса удивительных открытий. Вроде cache, writeback, rwm-cycle, power outage.
Тогда хотелось бы услышать, как происходил процесс замеров.
Фрагментация и заполненность диска. Все отлично компилируется, когда диск пустой и свежий. Фрагментация диска влияет в разы сильнее.
И количество потоков. Вы копируете свой любимый фильм, а винда на фоне там поиск оптимизирует. И скорость может посетить в разы по сравнению со старыми дисками.
Или проводник открыть, который тут же любезно начнет выкраивать thumbnails.
Или накачать туда торрентов. Или притащить бэкапы Syncthing.
Да просто забить на 90-95%, и регулярно удалять старое и добавлять новое.
Кэш thumbnails лежит на системном диске.
Thumbs.db
Продолжайте, прошу вас)
С вами нужно начинать, а не продолжать. И начинать придется с азов. С устройства механического диска. С того, что такое время ожидания и как ему мешает rmw. С математики. С чтения спеков.
И когнитивные искажения, их придется изучить тоже. Особенное внимание уделить систематической ошибке выжившего, генерализации частных случаев и смещению выборки.
А сейчас вы даже огласить условия постановки эксперимента не можете, не говоря уже о проверке на корректность.
Thumbs.dbC:\Users\censored\AppData\Local\Microsoft\Windows\Explorer\
дальше читать не стал, извините
Еще с висты, ага. Осталось объяснить, откуда все время брался этот файловый мусор при том, что ни одной машины с XP или младше в хозяйстве нет уже лет 8, включая виртуалки.
дальше читать не стал, извините
Не извиняйтесь. Каджит прекрасно понимает, что чтобы иметь свое мнение — разбираться в предметной области вообще не нужно. Это ж не корректная постановка эксперимента, учет сайд-эффектов и прочая высоколобая мура, это ж просто мнение.
По указанному пути навалено 100 МБ.
Регулярно удаляю
thumbs.db, когда захожу в любую папку с картинками через Total Commander (просто потому что они меня раздражают). При каждом следующем открытии папки в Explorer thumbs.db появляется снова.
качает с предварительным созданием целого пустого файлаВ случае с SMR это бесполезно. Данные на SMR-диск всё равно будут записываться вразнобой. И записываться они будут не в те самые блоки, которые предварительно запишутся нулями при создании пустого файла. В итоге запись будет выполнена дважды, первый раз впустую.
То есть, методикой вы никакой не пользовались, и даже уверенности, что отключили кэш ОС и тестировали не PMR-cache у вас нет.
Nuff said.
Так что нет у юзеров таких задач. У бэкапного хоронилища — есть, а у юзеров нет.
Подавляющее большинство "обычных" юзеров домашний NAS (или просто внешний диск) используют именно как бэкапное хранилище, скидывая туда огромные аудио, видео и прочие большие и толстые файлы, плюс много пусть и не особо толстых, но всё же подряд — фотографии, ясный пень.
Потом из этого хранилища много читают (как сам юзер так и другие члены семьи), в очень случайном порядке, но вот запись за него происходит в основном последовательно и большими кусками.
У меня уже больше двух лет в таком качестве служат парочка Seagate Archive (ST8000AS0002), собранные в RAID1 (mdraid) и с ext4 в качестве fs — в основном только запись, архив файлов плюс бэкапы со всего (borg, rsync) и периодическое удаление старых бэкапов (то есть всё же перезапись происходит периодически).
Так вот — в таком режиме всё отлично работает, тормоза совсем не замечаются, таймаутов при работе нет, скорость записи ~ 60 MB/s (да, маловато, но всё равно даже в теории выше 100 MB/s не прыгнуть по сетке), скорость чтения ~ 200-130 MB/s (в начале и конце диска соответственно), т.е. для функции "хранилище" всё просто замечательно.
Этот примерно так и сказал, и вы даже процитировали.
Но: в вашем сетапе есть NAS, не так ли? То самое хоронилище.
Если такой диск оказывается у юзера, то он, скорее всего, единственный. Вообще. И на нем будут и система, и игры, и мультимедиа.
И вот тут-то разница прямо бросается в глаза.
Правда юзер замечает что с диском что-то не то только когда тот уже умер и все равно этого не увидит.
Понятно, так бы сразу и говорили — "юзер" — это чувак (или чувиха) с одним диском. Впрочем, реальность несколько более разнообразна, знаете-ли, даже домохозяины и прочие юзеры используют NAS и просто внешние диски.
Но если уж брать среднего юзера который просто шарится по сети, хранит на компе все свои медиа-файлы и играется в игры — уверяю вас, он скорее всего не заметит разницы в скорости пока не попытается дефрагментировать тот самый диск, в худшем случае проблемы начнутся если он увлекается торрентами, но торренты — это ничтожный процент всех пользователей, особенно за пределами РФ, всё остальное не создаёт достаточной рандомности доступа по записи чтобы оказывать существенное влияние.
Хотя очень маловероятно что типичный современный десктопный юзер получит в качестве единственного диска нечто с SMR — сейчас в качестве системного (и иногда единственного) принято ставить SSD, а если не SSD — то нечто до 1T размером, там практически нет SMR.
В общем, опасность и недостатки SMR для "среднего" юзера очень сильно преувеличены, на мой взгляд — могут быть кейсы когда это будет больно, но их очень мало (напомню ещё раз — торренты — это всё же нетипичная нагрузка).
уверяю вас, он скорее всего не заметит разницы в скорости пока не попытается дефрагментировать тот самый диск
то-то нас все учат, что дефрагментировать не надо ))))
Дак юзер он и есть user — самый что ни на есть рядовой пользователь. Ни в чем не разбирается, при попытке выспросить характеристики железа делает глазки лягушечкой. И на вопрос сколько у него дисков вряд ли ответит.
Хотя очень маловероятно что типичный современный десктопный юзер получит в качестве единственного диска нечто с SMR
Купив ноутбук, хотя бы. Или готовую сборку. Или "чтобы подешевше".
Каджиту 2ТБ smr достался именно так, после замены на ssd в клиентском буке.
типичный современный десктопный юзер получит в качестве единственного диска нечто с SMR —… поскипано… — то нечто до 1T размером, там практически нет SMR
Silicon Power Armor 30 1 Tb именно черепичный фигейт там и стоял. До отказа насовсем на ровном месте.
Я многочитал, выбирая очередной бюджетный SSD, и сложил чёткое убеждение: просто так много кэша не кладут. Это нужно, чтобы сгладить вероятные, известные производителю, затыки. Ну, теперь и до жестких дошла тенденция.
Больше кэша на HDD — всегда хорошо, даже на самых быстрых моделях. Больше кэша на SSD — тоже всегда хорошо, сокращает износ и всё такое.
Сам факт наличия большого кэша далеко не всегда говорит о попытке что-то сгладить или скрыть — к примеру, серия Seagate Exos E/X имеет кэш 256M, некоторые тошибы серии энтерпрайз — аж 512M, при этом они совсем не SMR и очень даже производительны.
Другое дело что независимо от размера кэша всегда найдётся некая модель использования которая сведёт на нет все достоинства этого самого кэша.
И наконец, если кэш всё же существует только для того чтобы "сгладить", и при этом у него получается — то в чём собственно проблема? Важно ли что внутри если снаружи всё работает как заявлено в спецификации?
Кэш хорошо, но, как известно, много кэша — это хуже, чем мало быстрого кэша. Это раз. Два. Кэш нужно уметь инвалидировать. Понятно, что если в накопителе кэш на запись, то ты его полностью забил — дальше просадка по скорости, накопитель в фоне скидывает его на блины — гарантий того, что данные доедут нет. Нужно это учитывать. А тут начинаются приколы с оптимизациями от производителей — прошивка для нас черный ящик. На чтение же… Ну, кэш, скорее благо, но тут вопрос в том что операционная система сама кэширует — ну, и что получается — непредсказуемая каша из кэшей разных уровней. Я где-то видел хороший кейс cache pollution, но сейчас прям ссылку не найду
У каджита прямо вот, под руками, лежит такой. ST2000LM007-1R. Усыпанная бэдами 320-ка от гнусмаса — шевелится быстрее.
Сигейт понял свою ошибку с СМР дисками и пытается исправляться.
ВД изначально пошел по другому пути, поэтому ПОКА ЧТО их СМР диски быстрее на рандомной записи, чем у Сигейта. Особенно если забивать не весь диск, а оставить треть диска пустым.
У Сигейта же все СМР ленты, в которые хост пытается писать рандомно, записываются в отдельном месте (наверняка небезызвестном вам Media Cache), а затем в бэкграунде собираются в непрерывные куски в другом месте, которое называется Media Scratch Pad и уже потом записываются в юзер зону.
Когда медиа кеш забивается данным, наступает полная пичалька и диск очень хочет скинуть эти данные в юзер зону и начинает жестоко тупить.
Размер медиа кеша всего-навсего 50-100ГБ, а у ВД, с их трансляцией — весь диск считай под кеш отдан. Соответственно при непрерывной рандомоной записи более 100ГБ на такой Сигейт, гарантированно наступит эцих с гвоздями.
Так вот, Сигейт, как я уже сказал, исправляется и выпускает новые драйвы, у которых СМР транслятор будет использовать и медиа кеш и юзер зону как медиа кеш, пока она еще пустая — скорость должна сильно вырасти.
Но что ВД, что такой новый Сигейт все равно начнут тормозить, если свободного места останется мало (прямо повеяло ССД-ями)
Ну, в общем — как обычно — технология сырая, потребитель страдает, ждём патчей и обновленных устройств с исправленными проблемами
прямо повеяло ССД-ями
Любопытно, понимает ли он запись нулей как эквивалент освобождения блока?
Особенно если забивать не весь диск, а оставить треть диска пустым.Вот в этом месте пьеса достигла просто патетического надрыва :) SMR — технология, которая позволяет на четверть увеличить объем. Нормально работает, если треть оставить пустой.
Зато на zfs можно будет на голубом глазу установить на весь пул квоту 75% и избежать перехода на неэффективный аллокатор.
Но да: это, скорее, смех сквозь слезы.
Нормально работает, если треть оставить пустой.
нормально работает НА НЕПРЕРЫВНОЙ РАНДОМНОЙ ЗАПИСИ, если вы пишете большими кусками, то все будет ОК, даже если диск целиком забить.
Но эти диски не для BTRFS или ZFS, это да.
Старый добрый Ext4FS спасет отца русской демократии.
Опять же для end user-ов не имеет большого значения, как работают эти диски в ZFS, так как они используют обычно внешние драйвы для хранения картиночек и всяких мемасиков.
Даже если это будет домашний NAS, то все равно на него не будет идти запись 24/7.
Вобщем SMR это малое зло.
Все ждем MAMR/HAMR с CMR-ом :)
Так что падения производительности никак не должно быть
Установив кеш приличного размера, можно сократить IO диска и уменьшить фрагментацию.
Не знаю уж будет ли клиент пытаться закачивать в кеш линейно или рандомно, но даже 128МБ непрерывной рандомной записи с последующей паузой лучше чем непрервное дерганье диска 512КБ-ми блоками
Видеонаблюдение подходит?
Новость и вправду отвратительная.
А какая непрерывная нагрузка в 100 Мб? да простая, домашняя: бэкап на полочку положить. В качалку-раздавалку торрентов поставить. Самые простые кейсы.
А насчёт «явно не предназначены»- об этом производители упомянули или надо догадываться?
Сейчас Storage Space c Tiered-Storage стоит на связке из SSD AMD R5SL240G + HDD Seagate ST1000DM010-2EP102.
Под нормальной рабочей нагрузкой — 60 баз 1С по 3-5 Гб в серверном варианте поl SQL — все крутится и летает прекрасно. Оптимизация уровней хранилища занимает от силы полтора часа. В это время система становится «слегка плавной», но тем не менее вполне отзывчивой и с приемлемым уровнем производительности, максимальная длинна очереди диска — 2-3. Но, если например, в течении дня обновить все базы, последующая оптимизация уровней хранилища с этим диском занимает до 26-28 часов, при том, что пока она не закончится — наблюдаются дичайшие тормоза и длинна очереди диска вырастает до значений в 15-20.
До установки Seagate ST1000DM010-2EP102, в этой связке стояла TOSHIBA MG03ACA100, и описанного поведения системы не наблюдалось никогда, независимо от количества измененных или новых данных.
Что тогда брать, чтобы избежать винчестеров, годных только для видеорегистратора?
Показатель весьма косвенный. Однозначно наличие smr определяет поддержка trim.
Не всегда определяет. К примеру, Seagate Archive не поддерживают trim/discard, хотя очень даже SMR.
Вероятно, вышло несколько неоднозначно.
Каджит хотел сказать, что если жесткий диск поддерживает trim/discard/unmap, то он точно smr, потому что больше никому такое не надо.
Но, да, технически smr-диск не обязан поддерживать trim.
Однако, в отличие от размера кэша, поддержка trim однозначно говорит, что диск отличается от обычного.
у WD классически весь секрет в цифирках после номера модели.
Условно WD10EZEX-08WN4A0 может быть одним типом накопителя, а -22BN5A0
Извините, что капитаню, но я с WD наелся уже. Даже Сигейт идентифицировать всегда было проще друг от друга (по полной модели STxxxxxxxxx).
Проблема лишь в том, что вот эту полную модель получить никоим образом нельзя из оф доки wd, а приходится экспериментально считывать из паспорта накопителя и соотносить с параметрами на опыте
Соответственно стоит пойти на сайт Хитачи и почитать про их модели, какие с СМР, а какие нет.
Но имейте ввиду, WD по умолчанию поддерживают multi-stream, т.е. при записи/чтении в 2-3 потока, скорость диска равномерно размажется между этими потоками.
А у Хитачей в таком режиме производительности прихрамывает (у не-eneterprise Сигейтов вообще отсутствует)
А если напрямую у производителя запросить инфу перед покупкой, они ответят? По идее они о своей продукции обязаны разъяснить ВСЕ ттх. А если не верно ответят (соврут), могу я потом забрать свои деньги и вернуть диск?
Так НЖМД уйдут в нишу магнитной ленты, став накопителями с затруднённой случайной записью. Да и то, лента выигрывает в энергоэффективности, что для архива критично.
Я думаю, это повод поднять цены. Думаю, через некоторое время цена SMR дисков повысится совсем незначительно, а вот не SMR будут гордо маркировать огромной надписью и задерут ценник до небес. Маркетинг… "хлопья_без_асбеста.jpg"
Извините, но так и не уловил смысл этой черепичной записи. В чем смысл записи более широкой чем для чтения головкой? Или запись более узкой головкой физически невозможна? Или её нельзя так точно спозиционировать?
Ну да, примерно так, что надёжно записать более узкой головкой не получается.
Или запись более узкой головкой физически невозможна?Да. Дело уже не в головке, а в конфигурации магнитных полей, они так просто не хотят делаться у́же.
Смысл примерно такой же, как с 4k/512e — плотнее размещать данные. Но при этом одиночная запись 512-байт сектора приводила к чтению 4к-блока и записи его обратно (rmw-цикл, чтение-модификация-запись), что давало штраф в виде ожидания одного оборота диска. При использовании неправильного выравнивания это приводило еще и к тому, что операция записи каждого 4к-блока приводила к чтению и модификации уже двух 4к блоков.
В жестком диске головка позиционируется обычно быстрее, чем ожидание времени подлета сектора, поэтому производительность случайного ввода-вывода определяется скорость вращения пакета дисков. Десктопные диски крутятся на 7200 rpm, 7100/60=120 оборотов в секунду. Среднее время ожидания (сектор может быть в произвольный момент времени как на подлете, так и только что улетевшим) принимает за половину оборота, что дает теоретически достижимую производительность в 240 IOPS. Если требуется сперва прочитать блок, а потом его записать обратно, то надо прождать средние полоборота и потом еще целый, то есть, среднее время ожидания увеличится втрое, а максимальная производительность упадет до 80 IOPS.
При этом между дорожками всегда есть промежутки, исключающие наползание дорожек друг на друга.
В случае SMR наползание превращается в фичу. Но из-за этого записывается за раз только блок дорожек целиком, и для изменения одного 4к-блока надо перезаписать несколько десятков мегабайт.
Допустим, для простоты счета, что друг на друга наползают 4 дорожки. В этом случае rmw-цикл потребует 0,5 оборота на ожидание начала блока, 4 оборота на чтение smr-блока, 1 штрафной на ожидание (его мы уже видели) и еще 4 на запись его обратно. 0,5+4+1+4 ≈ 10, ухудшение производительности составит 10/0,5=20 раз, 240/20=12 IOPS.
При этом если есть достаточное количество пустых smr-блоков, то линейная запись будет оставаться довольно быстрой.
Помимо прочего, в случае рандомной записи данные будут прокачиваться через кэш накопителя (где они будут модифицироваться перед записью обратно), что дополнительно повышает вероятность их испортить из-за ошибок ram.
Не говоря уже о повышенной нагрузке на механику диска.
Учитывая, что статистически ожидаемая вероятность ошибки для консьюмерских дисков уже не позволяет считать объем диска без нескорректированых ошибок…
При этом ничто не мешает им притворятся почти нормальными, особенно, пока диск почти пуст.
Что-то технология выглядит совсем «не очень»
Каджит уже не раз сказал за сегодня — это хорошо ложится на разные хоронилища. Много записи большими кусками, крайне редкая перезапись, основная нагрузка — простой и редкое чтение.
Брать такой диск как системный (хм, в 2020 кто-то еще использует жесткий диск для системы?) или для какой-либо активной работы — так себе идея.
Ухищрения, к сожалению, уже практически везде. Лучше мониторить форумы вроде ixbt, чтобы не ошибиться. Как косвенный параметр, можно ориентироваться на цену. Если два абсолютно одинаковых диска отличаются в цене на четверть, то есть вероятность что более дешовый как раз с smr.
Прошу прощения за оффтоп, но уж больно интересно — почему Каджит говорит о себе в третьем лице?
Потому что каджит )
http://elderscrollsonline.su/kadzhity-koshki-tamrijelja
Насчёт бОльшей головки записи — как я понимаю, достигнут предел сегодняшних технологий для обеспечения надёжной записи при растущей её плотности. Поэтому в виде черепичной записи нашли ресурс для дальнейшего повышения плотности записи, но ценой производительности накопителя.
Похоже, что лучшее применение таких винчестеров это «холодные» данные и задачи, где случайная запись сведена к минимуму, например видеорегистраторы и в стандартных задачах их стоит избегать.
Выглядит как бага в фирмвари. Какая разница откуда читать?
WD снова отличилась.
Да лучше прям как во время DTLA/DDYS/AVER — стеклянные блины, а чо — модно. Представляете себе убийственное сочетание? Гелий, стекло, SMR! И еще крышечку прозрачную
Вот так https://festima.ru/docs/182495250/moscow/hdd-wd-raptor-x-wd1500ahfd-150gb-bu-redkiy
Ээээ… хитачи разве не до конца производили стеклянные блины?
Но даже если нет, проблемы тех винтов не в блинах были, а во флюсе.
Да и если диск не пинать, стекло не крошится, а если пинать — то диск не жилец.
Нет, со флюсом (это общеизвестно) — проблемы были у фуджей. Cirrus logic и все такое. После серии mpg им пришлось уйти с рынка десктопных накопителей. Но вот ноутбучные и серверные они ещё очень долго делали и они были прекрасны. Пока их не купила вроде бы Хитачи.
А с айбиемками там вообще интересная история была. Реальная катастрофа из-за неудачного стечения обстоятельств. Начиная от багов в фирмваре, неудачном игольчатым контакте между гермоблоком и контроллером (лечилось простой пропайкой), да ещё и стеклянные блины, с которых магнитное покрытие слезало. Жесть, короче.
мне казалось, там что-то с механикой, то ли головки, то ли шпиндель
Я вообще не понял проблемы. Мне вообще по барабану, что там внутри SMR, не-SMR, лишь бы реальное поведение диска соответствовало ожидаемому. Касательно нюансов — я помню какую свинью подложили WD, когда перешли на Advanced Format — там реально при неудачной разметке диска можно было всерить более половины производительности (когда по факту — у тебя пишется два смежных сектора по 512 байт, а они попадают в два физических сектора по сколько там -по 4KB?). Но по крайней мере быстродействие было единственной проблемой — сам диск превосходно работал и не давал IDNF при протормозках. Вообще IDNF выглядит как нарушение стандарта, а рейд контроллеры тоже молодцы — выкидывать диски без причины. Давайте рейды запретим, а?
И, да, журналисты как обычно… изнасиловали технарей в мозг
Комментарий чуть выше:
Допустим, для простоты счета, что друг на друга наползают 4 дорожки. В этом случае rmw-цикл потребует 0,5 оборота на ожидание начала блока, 4 оборота на чтение smr-блока, 1 штрафной на ожидание (его мы уже видели) и еще 4 на запись его обратно. 0,5+4+1+4 ≈ 10, ухудшение производительности составит 10/0,5=20 раз, 240/20=12 IOPS.
И это в нормальном режиме работы. Что будет, если наложится фрагментация данных на массивный IO — даже думать не хочется. На \r можно найти сообщения о падении скорости до 12-16 МБ/с при линейной записи, что косвенно подтверждает правильность прикидок.
Повторюсь, что пока накопитель работает в установленном режиме — все ок. Проблема только лишь в том, чтобы получить от производителя четкие критерии того, что с какой скоростью должен накопитель работать. Пример с advanced format я приводил — накопитель исправен — скорость в Ж*. Даже линейная. Не говоря уже о случайном доступе. Является ли это причиной для возврата? Ну, вряд ли.
На \r можно найти сообщения о падении скорости до 12-16 МБ/с при линейной записи, что косвенно подтверждает правильность прикидок.
ну, печально, согласен. Ожидаешь от современного накопителя что-то в районе 100MB/sec по всей поверхности (я очень давно и плотно развлекался тестами victoria/mhdd и мониторил обзоры, пока не пришла эпоха ssd).
Ну, тот же AF дает ухудшение IOPS всего втрое в худшем сценарии, которого легко избежать правильным выравниванием и установкой размера блока фс (clustersize, ashift, etc).
Тут же никаких гарантий нет и в принципе быть не может. В том-то и проблема.
Тут же никаких гарантий нет.
ну, я запросто могу гарантировать, что для любого накопителя я подберу самый плохой именно для него сценарий работы (даже с включенным буфером), в котором он будет по скорости как магнитная лента. Типичная история — это работа с кучей мелкий файлов на запись.
Повторюсь, что проблема преувеличена очень сильно за счет того, что ожидания не совпали с реальностью. Является ли это просчетом WD? Наверное, да — потому что ожиданиями клиента надо управлять. Было бы честно информировать клиента о скоростных характеристиках накопителя? Да, потому что цифры типа "sustained rate" абсолютно не говорят о реальных скоростных характеристиках.
Ну, и вообще отдельная история — это спецификации
Вот открываю рандомный диск — https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/public/western-digital/product/data-center-drives/ultrastar-dc-hc500-series/product-manual-ultrastar-dc-hc530-sata-oem-spec.pdf
Probability of not recovering data is 1 in 10^15 bits read.
SRSLY? На минуточку — это диск на 14Терабайт!!! Т.е. 1.12e+14 битов чисто самой емкости (если я не обдолбался с рассчетами). Ну, и консумерских этот параметр надежности еще ниже (1 из 10^14)
В целом согласен. однако
Повторюсь, что проблема преувеличена очень сильно за счет того, что ожидания не совпали с реальностью
Ну, как сказать. Покупая пастеризованное молоко определенной марки, ожидаешь, что оно простоит в холодильнике неделю. Особенно, если оно до этого нормально стояло 10-12 дней.
Если оно вдруг стоит всего два дня — значит, при покупке обманули покупателя, впарив тихой сапой или другой товар под той же маркой, или просрочку.
Появись вместо WD Red Pro — WD Red Light или WD Red SMR Edition — это было бы норм. а так произошла подмена устройства на другое с заведомо худшими характеристиками.
Претензии-то не к SMR как к технологии — повторюсь, для нее есть применение в сверххолодных или бэкапных хранилищах как минимум — а к целенаправленному обману.
sustained rate
Оно вообще непонятно как измеряется.
Ага. Только у хдд все ещё остаётся преимущество — их можно писать, класть на полку и, условно, через год данные там останутся. На ssd, была недавно тут на Хабре статья, Флэш память теряет данные, т.к. стекает заряд (фейспалм)
Типичная иллюстрация принципа, что бекап нужно регулярно проверять, иначе это не бекап
эти DVD-R стабильно хранили информацию 10 лет
к сожалению, у меня с ними негативный опыт
а сколько смогут хранить те которые купить можно, станет ясно через 10 лет (или раньше, если все плохо).
соглашусь
Пока, наибольшей стабильностью отличаются магнитные ленты, но и тут в новых технологиях нельзя быть уверенным (более высокая плотность записи рано или поздно приведет к снижению срока хранения).
еще вариант — облако, и побольше копий (вопрос только лишь в том, что это реально может стать дорого)
для целей длительного хранения больших массивов информации ни одна доступная технология не подходит
Магнитная лента. Стоит меньше, не требует электроэнергии при хранении, хранится десятилетиями.
Вот вам пример: нашел кассеты (dds) со старыми архивами примерно 15-летней давности, купил стример. Все кассеты успешно прочитались.
Да и купить исправный стример двадцатилетней давности может быть непросто, там механика и резина подвержены естественному старению.
Вы уверены что прочтете кассету LTO-8 через 15 лет?
Не уверен, да и как тут можно быть уверенным на 100%? Но есть положительные примеры. Например вполне реально найти живые стримеры LTO1, например, а ведь с момента создания прошло 20 лет. К тому же чтобы прочитать кассету LTO1 нужен стример 1, 2 или 3 поколения, их живых полно. Да и более старые вполне себе живут.
А чтобы прочитать LTO8 нужен будет привод 8-10 поколений, если будет сохраняться стратегия обратной совместимости.
Другой вопрос, что сейчас LTO8 очень дорог, не для дома однозначно. Зато 4-5 поколение можно найти за вменяемые деньги. Под архив сериалов — самое то))
p.s. Возможно, используя диск восстановления windows10 восстановить систему с ленты?
Не знаю, сматывают ли пробег у стримеров, по внешним признакам, выглядел он вполне неплохо.
SAS контроллер в самосборном NAS — вещь, зачастую полезная и необходимая сама по себе, да и стоимость умеренно старого SAS HBA не то чтобы очень велика.
Скорее проблемой будет нормально охладить всё это железо, и стримеру и HBA очень желательна принудительная вентиляция.
С другой стороны, учитывая специфику работы с лентами, думаю, далеко не всякому подобное устройство будет полезно, хотя поддержка LTFS может сделать их гораздо полезнее для обычного пользователя.
С LTFS пока не игрался, FreeBSD поддерживает её только для приводов IBM.
Насчёт диска восстановления. У HP есть какое-то ПО, позволяющее восстановить систему непосредственно с ленты, честно говоря, не интересовался этим вопросом, как и вопросом, как не покупая новый стример стать счастливым обладателем лицензии на это ПО.
Поскольку этот вопрос мне наверняка зададут, отвечу сразу, использую ленты для периодической архивации бэкапов и как средство резервного копирования, если больше записать некуда (например, при реорганизации хранилища под бэкапы), кроме того, лента бывает полезна для всяких архивов из категории «удалить жалко, хранить негде». Лентам я доверяю не больше чем жёстким дискам и прочим носителям информации, всё важное хранится строго в нескольких экземплярах и на лентах и на дисках одновременно.
Disaster recovery — немного другая задача, но восстановить с ленты на голое железо могут продукты Acronis(версию сейчас не вспомню) и вроде бы Veeam (не пробовал). Не реклама, если что.
Алгоритм при покупке стандартный.
Через интернет-магазин обязательно.
После покупки тестируешь диск и в случае SMR, возвращаешь обратно.
С причиной «цвет диска не гармоничен с цветом моего системного блока».
Впрочем можно обьяснить и реальную причину.
Если речь об этой табличке, то ее принес сам автор поста, каджит просто откомментировал.
PastorGL программа есть на офф.сайте WD, но тот что слева на картинке — щёлкать не перестал.
Можно пояснить — зачем диску TRIM? И как это взаимосвязано с SMR? Или диски стали настолько умны, что LBA сектор (который снаружи виден операционке) уже вообще никаким образом не связан с физическим сектором на блинах? Ну, примерно как уже в SSD сделано (но там на это хотя бы есть физические причины из-за особенностей страничного хранения данных во флэш памяти)
Кстати говоря, следствие всего этого — ждем багов в фирмваре SMR дисков. Не может это усложение пройти бесследно (вспоминаем многочисленные баги транслятора в HDD).
LBA кстати говоря, уже давно не связан с физическим местом на блинах, диски прозрачно для пользователя переназначают сектора которые физически неустойчивые.
на самом деле это полуправда. Действительно, диски умеют с помощью P-List и G-List исключать бед-сектора из пользовательской зоны (первый список закладывается на заводе, второй пополняется секторами в процессе постоянного сканирования диска с ремапами из резервной области), есть еще вообще служебная область, которая недоступна через LBA (там специальный набор команд со своей адресацией, можно условно представить как отрицательные LBA). Так что — да, действительно есть трансляция из логики в физику (возможно, что через какое-то промежуточное представление). Но и нет — как правило она максимально простая, как я описал, что и доказывается графиками линейной скорости чтения и записи дисков (они, графики т.е., идут от более быстрых секторов в начале диска, к более медленным в конце, причем явными ступеньками)
не уверен. График в случае ремапа (т.е. попадание сектора в G-List + соответствующая симптоматика в S.M.A.R.T.) — всегда страдает. Лечилось только реформатом накопителя на специализированном стенде (типа PC3000), но там отдельный вопрос как долго такой франкенакопитель протянет — т.к. деградация поверхности не просто так происходит
Но и нет — как правило она максимально простая, как я описал, что и доказывается графиками линейной скорости чтения и записи дисков (они, графики т.е., идут от более быстрых секторов в начале диска, к более медленным в конце, причем явными ступеньками)
Ваша информация уже устарела (для некоторых драйвов)
Ниже написал почему
От чтения забугорных манулов у каджита осталось какое-то такое впечатление:
SMR меняет размер блока аллокации с 4К на черти-что, плавающее в зависимости от радиуса группы дорожек. Мультизоновая запись, сэр. Кстати, не слишком удивительно будет, если решат избавиться от гапов в пределах дорожки, подперев ее дополнительно, например, sha, или что там неплохо ложится на железную логику. Но даже без этого, trim нужен, чтобы знать, в каких блоках уже нет актуальных данных и их можно с чем-либо рекомбинировать, потому что писать без тормозов можно только в полностью пустые smr-блоки. Всей радости — стирать не надо.
Размер сектора, естественно, эмулируется.
В результате, с поправкой на то, что это механика, оно работает идентично TLC/QLC диску, откуда эту идею, собственно, и уперли. Вместо динамического SLC-cache — статический PMR-cache (но это уже во второй инкарнации, DM-SMR).
Контроллер будет, в основном, попытками рекомбинировать дырявые блоки с мелкими записями, что обязательно приведет к внутренней фрагментации как у ссд.
В сухом остатке накопитель живет своей жизнью. Переносит блоки, тасует данные. Вытормаживается, когда ему приспичит и не факт что успеет выгрузит свои кеши в случае power fault.
В ближайшие годы, как этому кажется, добавят на такой случай флешку с ионистором, доведут PMR-cache до 10-15% емкости (при этом он займет где-то треть накопителя по площади), и вот вам sshd v2.
Больше всего страдают от такого поведения CoW. А учитывая, что накопитель постоянно тасует данные — а значит и bitrot будет встречаться существенно чаще — использовать ФС, не умеющие в чексуммы всего подряд, с такими накопителями это чистое безумие.
Кстати, бороться с тормозами на zfs будет, скорее всего, довольно легко: zfs set logbias=throughput sync=disabled. Но это из разряда вредных советов…
SMR меняет размер блока аллокации с 4К на черти-что, плавающее в зависимости от радиуса группы дорожек. Мультизоновая запись, сэр
Одно замечание. Как будто запись сейчас в нормальных HDD не мультизоновая, лол. Здесь более интересно другое — эти зоны раньше были вроде бы стандартными, потом производители оптимизировали распределение и их стали подбирать адаптивно для каждого накопителя в результате штатной процедуры заводского формата. Вплоть до — уникально для каждого блина диска. Но это абсолютно не влияет на физ сектор. Как он был у старых накопителей 512 (плюс какая-то служебная инфа), так и остался. Как он и у новых — 4К. Никаких адаптивных блоков не вижу. Я уж не знаю — может в SMR они там (производители) совсем кукухой поехали. Не видно.
Давно мультизоновая. Но контроллеру это дополнительные сложности при обсчете кого куда положить и с кем рекомбинировать.
физ сектор
Давно хост живьем не видит, примерно с тех пор, как контроллер переехал на hba.
Размер же логического LBA-блока остается 512/4096, с другими многие работать просто не умеют. А вот физически записать накопитель может только блок smr-дорожек за раз. Возможно получится дописывать в конец не полностью занятого блока, но точно не в середину.
Насчет раздувания физического сектора — это целиком мои соображения. Но раз уж пишем огромными кусками, то сохранять физические гапы внутри куска — незачем.
Лет через 5 допилят до юзабельности, вылечат детские болезни, драйвера ФС и кеши ОС, опять же, научатся правильно с этим работать — и будет нормально.
Ну, возможна определенная путаница. В целом согласен, но хотел бы обратить внимание, что есть накопители с логическим сектором 4096 — они не предназначены для работы в ширпотребных ПК, а скорее в спецоборудовании типа регистраторов. А есть AF, которые в паспорте АТА отдают оба значения:
ATA device, with non-removable media
Model Number: WDC WD10JMVW-11AJGS4
Serial Number: WD-WX91A96J7R4T
Firmware Revision: 01.01A01
Transport: Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
Supported: 9 8 7 6 5
Likely used: 9
Configuration:
...
Logical Sector size: 512 bytes
Physical Sector size: 4096 bytes
Logical Sector-0 offset: 0 bytes
внимательно слушает и записывает, потому как шанс самому увидеть это железо очень наврядли представится
Бывают ещё крайне забавные диски с размером блока в 520 байт. EMC очень любила таким баловаться, например.
Подтверждаю, когда-то интересовался этим. Где-то читал, что SAS диски можно переформатировать под 512. Но сам такого не делал.
Можно пояснить — зачем диску TRIM? И как это взаимосвязано с SMR?
У SMR дисков WD и у самых новых SMR Seagate трансляция host-LBA в disk-LBA проходит через дополнительный уровень трансляции, как на SSD.
К примеру вы пишите сектор 0 и надеетесь, что он будет записан в самое начало диска, но на самом деле, на таких дисках, он может быть записан куда угодно.
Делается это для того, чтобы сократить количество недописаных SMR лент (bands).
Т.е. все записи секторов от хоста (даже если вы пишете сектор 0, сектор 10000000 и сектор 3000 в трех последовательных запросах) сваливаются для начала в одну физическую SMR ленту (например в disk-LBA 0,1 и 2), что позволяет убить двух зайцев
1. Увеличить скорость записи, так как на не надо перечитывать всю SMR ленту, чтобы записать ее заново, но уже с новыми данными
2. Уменьшить время доступа, так как практически отсутствует операция seek при записи даже не последовательных секторов.
Так вот, этот SMR транслятор поддерживает TRIM, когда хост говорит, что сектора больше не нужны, диск выкидывает их из транслции и освобождает ранее занятые SMR ленты.
WD DC HC320 8TB (бывш. HGST) ~250$, если не торговаться
Тошиба MG06ACA800E с работающим кэшем записи ~230$
Вот поэтому и не перестаю удивляться который год любителям покупать WD.
Вот поэтому и не перестаю удивляться который год любителям покупать WD.
пока народ покупает, то и цена будет высока :)
некоторые вообще покупают по принципу «чем дороже — тем лучше»
WD RED pro 8TB ~360$
WD DC HC320 8TB (бывш. HGST) ~250$, если не торговаться
вполне вероятно, что это разные HGST модели, Хитачи очень плодовиты были последние 3-4 года
Я считаю, нужно показать THG, что мы не заметили подлога и ни в коем случае не писать на им, ни автору. Просто поворчать в уютном русскоязычном хабре и молчать дальше.
Тогда они продолжат держать нас за обезьян и сливать нам то, что не проканало на родине.
www.synology.com/ru-ru/compatibility?search_by=category&category=hdds_no_ssd_trim&filter_feature=SMR&p=1
У EFRX проставлена отметка, что они SMR
Интересно, я это пропустил, когда выбирал диски себе или же этой информации не было? Вангую что второе…
Как занятно это всё. Для чего же ещё сейчас покупать hdd обычному человеку (т е не Энтерпрайз и не на работу) если не в качестве домашнего хранилища? По-моему они решили самоубиться....
Они решили снять сливки с медленно умирающего рынка шпиндельных накопителей....
40-50ТБ ССД за $200 нам еще долго не видать, а HDD такие уже в этом году могут пойти
Так и тут, достаточно просто сделать SSD ещё немного дешевле. Не 40-50TB за $200, а хотя бы 4-8TB за $200. Это покроет потребности 99% рядовых пользователей, и HDD окончательно уйдут из обыкновенных ПК в специализированные хранилища.
Ох как не люблю я эти рассуждения про 99% мифических "рядовых пользователей".
Потому что куда ни посмотри — я, выходит, не рядовой пользователь вообще (даже не рядовой пользователь холодильника!), и всем на меня наплевать.
Искренне желаю и Вам, чтобы про Ваши потребности вот на таком же уровне всегда рассуждали.
Ну как-то потребительский рынок с этим справился, CRT ушли в анналы истории буквально за 5 лет,
Про замену HDD SSD-ями уже говорят 10 лет, если что.
Но пока что все никак.
Но продолжают говорить и приводить всякие примеры, типа мониторов, флоппи-дисков и прочего.
Почему-то забывая, что есть другие примеры. Например ленты хоронить начали с появлением относительно недорогих жестких дисков, уж сколько было разговоров, про то как «неудобно с лентой работать, там только последовательный доступ» и всякое такое. А ленты все живут и развиваются. Уже 30ТБ-е картриджи есть.
Так и тут, достаточно просто сделать SSD ещё немного дешевле. Не 40-50TB за $200, а хотя бы 4-8TB за $200. Это покроет потребности 99% рядовых пользователей, и HDD окончательно уйдут из обыкновенных ПК в специализированные хранилища.
потребительский рынок это даже не половина, это наверное 20% всех SSD и HDD
Теперь придется выбирать диски более тщательно.
Я выложу потом программу для определения SMR на GitHub'е, а также напишу на Хабре статью про методику правильного тестирования производительности дисков (вкл. тестирование на SMR), т. к. все бенчмарки сейчас работают абсолютно неправильно.
все бенчмарки сейчас работают абсолютно неправильно
смелое утверждение, поясните
Одним комментарием тяжело пояснить — это тянет на целую статью, причём немалую. Собственно, в статье и будет пояснение.
Но уже можно догадаться, что бенчмарки совсем не работают, т. к. SMR невероятно сильно снижает производительность диска (особенно в тех дисках, которые я имел, т. к. SMR в добавок в них сделан плохо), но эти программы не могут показать производительность диска при SMR. Включая те программы, которые запускают бенчмарк надолго и показывают изменение во времени — ничего общего с реальностью они тоже не имеют. Также они НЕ могут явно показать производительность до заполнения кэша SMR и объяснить, как она работает.
Разумеется, больше всего это влияет на SMR-диски, но и на обычных дисках эти программы тоже обычно выдают неверные результаты, хоть и не настолько неверные, как в случае SMR. Эти программы много чего не учитывают — такое чувство, что их просто писал студент, вообще не понимающий принципов работы дисков. Если кто-то думает, что тот, кто пишет их, разбирается в теме лучше Вас (если Вы тоже программист), могу Вас огорчить — никаких особых познаний они обычно не имеют, их познания не выше Вашего.
Разумеется, я не исключаю, что может есть люди, разобравшиеся в теме также, как и я, и тоже написавшие статью на этот счёт и правильный бенчмарк, т. к. ничего сверхсложго здесь нет, в принципе любой может разобраться. Но я пока не видел их. Если кто видел — поделитесь. При этом нужно понимать, что такой бенчмарк должен быть достаточно новым, т. к. SMR появился недавно. Разумеется, такой бенчмарк также должен уметь определять, является ли диск SMR-диском или хотя бы объяснить, как определить.
Знание кишок должно только помочь найти хороший крайний случай — среди реалистичных.
Хороший тест дложен быть black-box: имитировать известные типичные workloadы разных типов, ровно как выше в комментах — винда строит превьюшки, установка magic goody, юзер качает торренты, юзер скачал пол лирусека и случайно перезапустил торрент так что он начал перечитывать и передокачивать, компиляция ядра от рута и компиляция ядра внутри контейнера, ребилд ZFS и так далее.
и вот там и смотреть на как диск справляется. если у SMR кеш CMRа в 50% диска — то может оно и норм?
Хороший тест дложен быть black-box: имитировать известные типичные workloadы разных типов
Так как раз таки эти бенчмарки даже близко не имитируют типичные workload'ы. Вообще.
И даже просто производительность в тестах не могут написать — она ничего не имеет общего с реальной производительностью.
В итоге нет ни того, ни того. Вообще ничего нет.
если у SMR кэш CMRа в 50% диска — то может оно и норм?
Не знаю, может и норм, я сталкивался только с кэшом от 0.025% до 0.8%. С ним точно не норм. В любом случае, чем больше кэш, чем лучше будут результаты в бенчмарках. И дело даже не в том, что кэш влияет на то, сколько данных можно записать в него, а в том, что даже когда кэш уже заполнился, он очень сильно влияет на то, какая скорость будет уже после заполнения кэша. Это из-за особенностей SMR.
И да, и нет. Все очень сильно зависит от того какой алгоритм внутри прошивки. Условно — ну, показали бы вам 128 МБ кэша из 256МБ, а остальное — чисто под какие-то внутренние оптимизации. Стало бы легче пользователю от этого ?
Там кэш не для чтения используется, а для записи, это совсем разные вещи. Хотя в реальных дисках, которые были у меня, были жёсткие ограничения на количество записей в кэше, таким образом, если ты пишешь одновременно большие записи и маленькие, кэш мог заполниться лишь на небольшую часть, что ещё больше уменьшает скорость (скорость условно пропорциональна размеру кэша до тех пор, пока не упрётся в скорость чтения непоследовательных блоков с кэша + скорость линейного чтения с SMR-блоков + скорость линейной записи в SMR-блоки + IOPS на запись расположения новых блоков (которые всегда кладутся в кэш; вероятно, 1 IOPS на блок) + скорость непоследовательной записи новых блоков в кэш).
Если пишем линейно, чтение и запись в кэш, вероятно, могут не требоваться, данные могут взяться напрямую с ОЗУ. Если кэш SSD SLC, а не HDD PMR, операции с кэшом будут почти бесплатные (что юзается в реальности, я пока не тестил), но такой кэш очень дорог + подвержен износу. Теоретически SLC кэш может юзаться, чтобы не уничтожить данные во всём SMR-блоке во время записи в случае отключения питания, но это ещё больше усиливает износ.
Но это всё очень примерно, т. к. пишу по памяти или вообще что-то ещё не проверял или додумал прямо сейчас, поэтому с огромной вероятностью я в чём-то ошибаюсь или пишу неверно. В статье я уже буду точнее писать, а пока меня не стоит воспринимать слишком серьёзно.
В дискетах шаговый двигатель, а не адаптивный поиск дорожки.
Помнится, был у меня в глубокой студенческой юности комп с флоповодом, который умел писать аж ДВЕ лишние дорожки на трехдюймовой дискете. Я, будучи молодым и непуганым остолопом, записал на них по 1.7 (или 1.8?) мб архивов рар. Исходники, то-сё.
Естественно, комп я потом кому-то продал вместе с магическим флопарем.
И естественно, ни один из имевшихся в округе флопарей не смог прочесть 82-ю дорожку.
Куча остолопских архивов немножечко пропала. :)
И я сомневаюсь, что драйвера именно удваивали дорожки — проще разогнать контроллер по частоте и писать больше секторов на дорожку, как делал незабвенный 1600.com
Кстати, можно было при форматировании задавать размеры каждого сектора отдельно, чем и пользовались какие-то совсем уж экзотические драйвера.
Можно. Сектор сделать размером с дорожку. + и — черепичных дисков, но без собственно перекрытия дорожек
Длинные сектора на дискете — это аналог AF-дисков (advanced format c 4-кб секторами). И кстати, на дискете не получится использовать сектор длиной во всю дорожку (не помню, почему — то ли ограничения на размер сектора в контроллере, то ли ошибки чтения вылезут).
Черепичная запись — это когда за счет частичного наложения дорожек растет их количество на диске. На дискетах это работать не будет хотя бы потому, что головка чтения там широкая и при частичном наложении дорожек будет читать две-три дороги сразу — т.е. шум.
Резюмируя — «ешьте что дают».
blog.westerndigital.com/wd-red-nas-drives
SMR (черепичные) жесткие диски без указания наличия SMR пошли в каналы продаж