Как стать автором
Обновить

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

Как я понимаю, для железного RAID-контроллёра есть повод пометить диск как неисправный, пока тот «тупит» раскладывая как надо то, что ему «налили»?..
Но при этом «налить» надо больше кэша — что-бы диск начал «тупить»?

А как к подобному отнесутся софтовые mdadm, ZFS и прочие? У них нет более тонких настроек для имеющихся дисков? Ведь они как-то различают HDD и SSD, например? Иначе-бы при наличии SSD все HDD диски периодически отваливались как «неисправные»…

Ну и для всяких WAFL это по-боку, вроде, должно быть? Они всегда пишут в чистую область, а уже потом «разгребают» данные, в моменты простоя?..

PS: В ЖЖ подробностей больше — возможно, стоит скопипастить часть в статью или, как минимум, хотя-бы дать ссылки на статьи в ЖЖ.

Я так понял, что диск не просто тупит, а выкидывает ошибку. Всё это очень похоже на сырость прошивки.

Нет.
Железный или программный контроллер не могут разобраться почему действие выполняется очень долго, и предполагают, что диск умирает. Они могли бы справиться с этим, если бы диск сообщал, что у него — СПИД черепичная запись, или руками пользователь бы подправил нужное значение, если бы пользователь опять же об этом знал. Но власти производители это скрывают.
Разгрести данные опосля будет тяжело, ибо будет выполняться ну очень долго. И опять же, диск должен сообщить, что у него такая беда, а ФС и ОС должны суметь сделать вот это всё. И, как обычно, если железо/софт сняты с поддержки, то кто и как эти новые способности будет добавлять?
Опять же, диск будет постоянно дёргать головами и писать-переписывать, а значит, время жизни будет сокращаться. И в это время он будет неспособен на свою обычную работу.
Как-то не стоит это всё +25% ёмкости, ПМСМ.
3dnews.ru/1008543
3dnews.ru/1008687
Полгода юзаю 8 дисков st2000dm008 в mdadm RAID5, которые как оказалось тоже с SMR, пока ни разу не отваливались. Хотя и гигантской нагрузки я им не давал.
Тут тонкость в том, что пока диск успевает разгрести кэш, т.е. его «наливают» не через край — то проблем и не будет.
Ну и RAID5 ещё и считает перед записью — на что то-же требуется время, которое так необходимо диску, что-бы кэш не переполнялся…
… RAID5 ещё и считает перед записью

Там XOR в подсчётах, то есть никакой паузы и ожидания фактически нет.
А как к подобному отнесутся софтовые 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 тоже в пролёте.

А можно прояснить мысль про борьбу с торрентами? Это, в смысле, если торренты качать на рейд-массив из этих дисков (т.е., писать кучу мелких блоков), то они отказывают и таким образом вред торрентам?

Условно. Торрент скачивается блоками по 4МБ, но чтобы записать 4МБ на диск, диск должен прочитать к себе в буфер 40МБ(условно), добавить к нему 4МБ новых данных и записать 44МБ на диск. А тут уже другие 4МБ и всё по новой. Причем не важно, 4МБ или 4КБ, читаем 40, добавляем новые данные и записываем. И именно массив дисков не нужен, хватит и одного.
т.е. яблочная APFS и виндовая ReFS тоже в пролёте.

яблочники скорее всего могут позволить себе ставить в imac отдельные серии накопителей, где не будет проблем. Либо SSD.

Новость плохая. Что такое SMR если не знаете — очень может быть вам и не надо. Это про тонкости организации дорожек на блине жесткого диска.
Если хотите мое объяснение
От Сигейта на Хабре
От NIX
(Кидалово.)
Если аббревиатуры непонятны — новость не для вас. Всё просто, легче фильтровать нужные новости от ненужных.
2gusia
пустило только в Recovery Mode — написал только потому, что читатели сильно посоветовали
1) эти читатели считают Хабр лучшим ресурсом по HDD?
2) когда не пускало
а) Ваша местная карма была отрицательной?
б) это не послужило Вам никаким «знАком»?
3) теперь, спустя несколько дней — Вы удовлетворены?
4) что еще я забыл спросить? (с)
5) спасибо за статью!
1 — вот что писали. Ну и на хабре у меня аккаунт есть, а много где — и нету. На муське еще есть — но там точно не в жилу :)

2а — да, -1. Не знаю уж за что — это моя первая публикация, минусовых комментов тоже не было.
2б — не-а :) мнение одного анонима — это точно не знак, это шум
3 — я даже удивлен. Приятно удивлен — ожидал более агрессивной реакции. Впрочем, 7 минусов набралось, так то все в целом нормально :)
4 — про здоровье — спасибо, хорошо. Надеюсь, как и у Вас ;)
5 — приятно быть хоть чуточку полезным людям
приятно быть хоть чуточку полезным людям
но людя неблагодарны: если писать редко и мало — будешь виноват в недонесении (и даже утаивании) важной инфы, а если много — то алармистом обзывают и минусуют.
И тут приходится каждому самому решать :(

Еще раз спасибо и успехов всяческих — не только здоровья, а и ваще!
Как я понимаю, для железного RAID-контроллёра есть повод пометить диск как неисправный, пока тот «тупит» раскладывая как надо то, что ему «налили»?.

Да, и это вполне нормальное поведение контроллера. Нефиг щёлкать клювом в RAID-е. Не успел ответить за отведенное время — извини, накопитель, но семеро одного не ждут. В лучшем случае ты тормозишь, в худшем — ты сыпешься, поэтому проще тебя заранее заменить от греха подальше.
Ну и вообще вся суть RAID в том что мы жертвуем объемом ради скорости/надежности, тогда как цель у SMR противоположная
Нет, raid бывают разные, одни только для надежности (RAID1), другие только для скорости (RAID0, который не жертвует объемом) и другие, совмещающие скорость+надежность
Это только «красных» дисков касается? А то я тут недавно наткнулся на WD Blue WD20EZAZ у которых 256 кеша, в отличие от WD Blue WD20EZRZ с 64. Цена одинаковая, что меня сразу насторожило.

А то может пора «нормальными» двушками закупаться, пока их из продажи не вывели. Они у меня в RAID6 на mdadm в домашнем NASе…
Пока никто не знает, но было мнение, что разный цвет у дисков WD может соответствовать одинаковому железу при разной (и то не обязательно) прошивке. Так что ваши опасения не на пустом месте.

А насчет закупаться — все помним, как быстро вендоры перешли на AF диски. Может и сейчас так будет. Но, надеюсь, как и прошлый раз довольно долго при желании можно будет найти. Так что впрок я б не закупался. А вот если прям сейчас надо — то да. Станут CMR диски редкостью — подорожают точно.
Лет пять назад у меня был массовый падёж «синих» винчестеров, затем прекратился, видимо диски где-то уронили «оптом».
разный цвет у дисков WD может соответствовать одинаковому железу при разной (и то не обязательно) прошивке

В зависимости от серии. Какие-то действительно одинаковые вплоть до прошивки, отличаются только активным пресетом (в интернетах можно найти утилиту, которая меняет в ней флаги), какие-то разные. Мне вот домашний Blue на 4ТБ попался такой, который можно перещёлкнуть флагами на Purple. Я частично это и сделал, чтобы он перестал постоянно парковать головы, и вообще поменьше тормозил.


Маркетинговый мухлёж, в общем.

WD Blue WD20EZAZ у которых 256 кеша, в отличие от WD Blue WD20EZRZ с 64. Цена одинаковая

Кроме кеша, у них существенно отличается вес. Так что да — у WD20EZAZ SMR

А вес тут при чём?

Количество блинов
450 грамм — средний вес HDD с одной пластиной. «Старая» версия (WD20EZRZ) весит примерно 600 грамм, что равно HDD с двумя пластинами. Вы всерьёз считаете, что WD увеличили «без хаков» в два раза плотность записи и кэш в четыре, и продают это по старой цене?
Кэша зря много класть не будут.
В зарубежных источниках упоминается, что на SMR перешли диски 2-6ТБ, 8 и далее, который были non-SMR, такого пополнения в модельном ряду не получили.
Упс, поправлю себя, в зарубежном thg, на который есть ссылка, этот момент как раз упоминается.
Все три производителя начали продажи...

так вот как выглядит невидимая рука рынка…
WesternDigital, а вы не хотите ничего сказать по данному поводу?
А заодно и SeagateRu.
Пользуясь случаем, так же передаю привет компании WD. Если вы читаете этот пост, то дайте ответ: почему в моём HDD вашего изготовления, на красной такой термопрокладке между контроллером и корпусом, внезапно!, оказалась плёнка? Вы их там вручную снимаете или станки «забыли» настроить? О контактах на плате плате, которые через 3 года в достаточно хороших условиях чернеют — молчу вообще. Ладно, если бы я такой один невезучий был, так нет — в сети масса жалоб, а воз и ныне там.
У Самсунга тоже чернеют контакты
image
Все же стоит быть честными.
Первое, они не заявляли что там нет SMR.
Второе, диски данных серий явно не предназначены для работы ZFS или RAID5/6, это домашние, максимум малый бизнес. Тем более не для непрерывной нагрузки в 100Мб/c.

Эм, а если у меня дома ZFS?

То пора скупать WD100EMAZ.
Я-то наделся пару 32GB Unbuffered ECC взять…

То нужно быть готовым, что кроилово (попытка собрать серверную систему из десктопного железа) приведёт к попадалову.

Если человек пытается в машину, изображающую сервер (домашний, не домашний, не суть важно), воткнуть условный Toshiba P300, предназначенные для десктопа, он заведомо ССЗБ.
Вы это ребятам из Backblaze скажите.
Ребята из Backblaze как раз и компенсирую попадалово. И действительно на большом кол-ве дисков это может быть оправдано, когда вы самостоятельно занимаетесь исследованием их поведения, сборкой, тестированием и отладкой конфигураций.
Но на одном — двух серверах это задача с не предсказуемым финансовым эффектом.

Эмм. Моему домашнему серваку с 6 3Тб дисками уже дай бог памяти лет 6. И работает. Нагрузка там смех и грех. Мне надо было WD Black брать чо бы дорохо бохато и тарахтело?

Цитата прямо из статьи


WD RED — WD Red EFAX — SMR диски и имеют 256 Мб кеша. Диски EFRX — не используют SMR (это обычные CMR диски) и имеют кэш 64 Мб

Или WD Red уже не для NAS?

Так вроде красные как раз позиционировались под NAS.
Интересно, если производители NAS не включат диски в совместимые или даже начнут предупреждать о несовместимости, чтобы к ним не было претензий.

Именно. И в них — smr. Без smr теперь WD Red Pro, но надолго ли?


Суть в том, что кроиловом не пользователь начал заниматься. А пользователь страдает из-за кроилова компании и использования ею dark paterns.

Нет там проблем с совместимостью, проблема в головах которые решили использовать домашние диски для не домашних задач. Поставьте red в типичный домашний nas в котором есть ипизодическая нагрузка на чтение и совсем редкая нагрузка на запись и никаких проблем с эти диском не будет.
По умолчанию mdadm, использующийся в домашних NAS, делает проверку массива по cron каждый месяц, но это не только полное чтение дисков, а и ремап в случае проблем. В «зоне риска» потенциально все NAS с > 2 слотами, т. к. возможен RAID 5.
Занудство
Потенциально, конечно, возможен RAID 5 на двух накопителях и 6 — на 3-4, но это пограничный случай, когда точно планируется расширение в будущем.

RAID-5 на двух это DEGRADED в RAID-0…
Особенно будет приятно получить полный развал массива при ребилде после добавления диска.

домашние диски для не домашних задач

Во-первых, граница домашний/недомашний больше существует в умах маркетологов.
Во-вторых, 20 ТБ, которые гелий и smr, делаются явно не для дома.
В-третьих, NAS это уже сервер.
В четвертых, прочитайте уже источники — как раз в одомашенных NAS и выяснились проблемы с этими дисками.

В пятых, типичная история — покупаем самый дешёвый накопитель на заказанный объем и не любим себя в голову. А потом. Упс, что-то пошло не так.

Самое забавное, что если бы действительно взяли бы самый дешёвый, то скорее всего это была бы Toshiba N300 или WD HC310 которые чистый PMR )


Но люди брали диск для NAS'а по конскому ценнику.

Диски smr без проблем будут работать в домашнем/smb nas
Но raid5/6 и 100мб/сек на запись в течении 40мин( а это 240гб ) явно не относится к классу задач домашнего nas.
А давайте пользователь сам будет решать, что к его задачам относится, а что нет.
Задача производителя тут попросту указать, что после трех минут интенсивной работы производительность деградирует. От сих — и до сих. Процессоры троттлят, это в спецификациях указано, и никто пока от такого указания не умер.

А дальше дело клиента решить, что ему больше надо: емкость, цена, стабильная работа или шашечки.
Да ладно, процессор. Это к шредерам указывают — 10 минут режет бумагу, 10 минут остывает и не работает. А тут диски.
Так-то ко многому указывают.
К миксерам кухонным и прочим мясорубкам — я просто взял пример из той же отрасли.
Приехать из отпуска с кучей видео и попытаться сохранить это в более удобное место — не задача домашнего nas? Ну ок…
Видимо бэкапы — не задача домашнего 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).
Все равно без дела валяется.

На Банан M1 чел из Израиля приделывал nas4free — до конца не доделал, но работало. И, как я понял (сам не тыкал палочкой) там с поддержкой железа производителем не ах. Так что если под ваш вариант что то готовое — тогда да (недавно был хабропост с OpenWRT). А самому :(

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 — не стоит.
Пару месяцев назад брал себе в нас 6шт MG07ACA12TE. Вся линейка MG07 без SMR. Отличные диски. Разве что шумные немного, но в домашней файлопомойке нагрузки нет и хрустят редко. Да, под помойку можно и SMR, но не стал рисковать.
диски данных серий явно не предназначены для работы 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-ка от гнусмаса — шевелится быстрее.

У меня 8-терабайтник с ебея с технологией SMR (ST8000DM004), скорость копирования файлов с фильмами порядка 130 МБ/сек. Вполне нормально.

Пфе! У каджита скорость копирования с nvme на usb2-флешку — 2ГБ/с.
Этот думает, вас ждет масса удивительных открытий. Вроде cache, writeback, rwm-cycle, power outage.

Нет, не ждёт, это реальная скорость записи.
Запускаете perfmon и смотрите, а в чём проблема?

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

Оптимизация поиска в винде — низкоприоритетная по вводу/выводу задача, и вытесняется при наличии нагрузки с обычным приоритетом. Не говоря уже о том, что на диске с фильмами нечего индексировать, и неоткуда взяться сколь-нибудь значительной фрагментации. Так что нет.
Фрагментация данных на диске. По мере увеличения фрагментации данных на диске скорость доступа на запись у SMR диском будет падать значительно быстрее.

Или проводник открыть, который тут же любезно начнет выкраивать thumbnails.
Или накачать туда торрентов. Или притащить бэкапы Syncthing.
Да просто забить на 90-95%, и регулярно удалять старое и добавлять новое.

Кэш thumbnails лежит на системном диске. Торренты utorrent качает с предварительным созданием целого пустого файла. Бэкапов чего вы там сказали у меня нет. Забить на 95% легко, регулярно удалять старое и добавлять новое — тоже, но при таких размеров файлов фрагментация от этого — какие-то сотые доли процента. Продолжайте, прошу вас)
Кэш thumbnails лежит на системном диске.

Thumbs.db


Продолжайте, прошу вас)

С вами нужно начинать, а не продолжать. И начинать придется с азов. С устройства механического диска. С того, что такое время ожидания и как ему мешает rmw. С математики. С чтения спеков.
И когнитивные искажения, их придется изучить тоже. Особенное внимание уделить систематической ошибке выжившего, генерализации частных случаев и смещению выборки.


А сейчас вы даже огласить условия постановки эксперимента не можете, не говоря уже о проверке на корректность.

Еще с висты, ага. Осталось объяснить, откуда все время брался этот файловый мусор при том, что ни одной машины с XP или младше в хозяйстве нет уже лет 8, включая виртуалки.


дальше читать не стал, извините

Не извиняйтесь. Каджит прекрасно понимает, что чтобы иметь свое мнение — разбираться в предметной области вообще не нужно. Это ж не корректная постановка эксперимента, учет сайд-эффектов и прочая высоколобая мура, это ж просто мнение.

Windows 10.
По указанному пути навалено 100 МБ.
Регулярно удаляю thumbs.db, когда захожу в любую папку с картинками через Total Commander (просто потому что они меня раздражают). При каждом следующем открытии папки в Explorer thumbs.db появляется снова.
Посмотрел в каталоге с фотками — есть такие файлы, но все за 15-17 года, новых нет. Возможно где-то что-то выключено. Превью отображаются нормально.
качает с предварительным созданием целого пустого файла
В случае с 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, но сейчас прям ссылку не найду

это где это вы нашли торренты с последовательной записью?
1) В комментарии не было ни слова про торренты, только про хранение видео/аудио/фотографий.
2) Достаточно большое число клиентов умеет качать последовательно. Обычно это нужно для просмотра видео без ожидания.
У каджита прямо вот, под руками, лежит такой. ST2000LM007-1R. Усыпанная бэдами 320-ка от гнусмаса — шевелится быстрее.

Сигейт понял свою ошибку с СМР дисками и пытается исправляться.
ВД изначально пошел по другому пути, поэтому ПОКА ЧТО их СМР диски быстрее на рандомной записи, чем у Сигейта. Особенно если забивать не весь диск, а оставить треть диска пустым.
У Сигейта же все СМР ленты, в которые хост пытается писать рандомно, записываются в отдельном месте (наверняка небезызвестном вам Media Cache), а затем в бэкграунде собираются в непрерывные куски в другом месте, которое называется Media Scratch Pad и уже потом записываются в юзер зону.
Когда медиа кеш забивается данным, наступает полная пичалька и диск очень хочет скинуть эти данные в юзер зону и начинает жестоко тупить.
Размер медиа кеша всего-навсего 50-100ГБ, а у ВД, с их трансляцией — весь диск считай под кеш отдан. Соответственно при непрерывной рандомоной записи более 100ГБ на такой Сигейт, гарантированно наступит эцих с гвоздями.
Так вот, Сигейт, как я уже сказал, исправляется и выпускает новые драйвы, у которых СМР транслятор будет использовать и медиа кеш и юзер зону как медиа кеш, пока она еще пустая — скорость должна сильно вырасти.
Но что ВД, что такой новый Сигейт все равно начнут тормозить, если свободного места останется мало (прямо повеяло ССД-ями)

Ну, в общем — как обычно — технология сырая, потребитель страдает, ждём патчей и обновленных устройств с исправленными проблемами

прямо повеяло ССД-ями

Любопытно, понимает ли он запись нулей как эквивалент освобождения блока?

Вряд ли (говорю из личного опыта, но не с smr)

понимает ли он запись нулей как эквивалент освобождения блока?

Нет. Я в исходном посте цитировал Алана Брауна — он какр раз делал такой эксперимент
нет, запись, это запись, даже если там одни нули
Особенно если забивать не весь диск, а оставить треть диска пустым.
Вот в этом месте пьеса достигла просто патетического надрыва :) SMR — технология, которая позволяет на четверть увеличить объем. Нормально работает, если треть оставить пустой.

Зато на zfs можно будет на голубом глазу установить на весь пул квоту 75% и избежать перехода на неэффективный аллокатор.


Но да: это, скорее, смех сквозь слезы.

Нормально работает, если треть оставить пустой.

нормально работает НА НЕПРЕРЫВНОЙ РАНДОМНОЙ ЗАПИСИ, если вы пишете большими кусками, то все будет ОК, даже если диск целиком забить.
Но эти диски не для BTRFS или ZFS, это да.
Старый добрый Ext4FS спасет отца русской демократии.

Опять же для end user-ов не имеет большого значения, как работают эти диски в ZFS, так как они используют обычно внешние драйвы для хранения картиночек и всяких мемасиков.
Даже если это будет домашний NAS, то все равно на него не будет идти запись 24/7.

Вобщем SMR это малое зло.
Все ждем MAMR/HAMR с CMR-ом :)
Но эти диски не для BTRFS или ZFS, это да

И не для ReFS, видимо.
Я качаю кинчики торрентами. По умолчанию там идёт скачивания случайных наиболее редких блоков. Ну и как будет чувствовать себя SMR под такой нагрузкой на 300 мегабитном канале?
На 200 мегабитном всё норм.
Так может включена последовательная загрузка. У uTorrent вообще занятные отношения с Windows, и при галочке «Распределять место сразу» винда начинает забивать место под файл нулями, и загрузка виснет при загрузке раздачи более 20 ГБ вне зависимости от ширины канала.
После создания файла загружает в него данные на вид рандомно расположенными блоками. Но размер блока 4 МБ, так что какой-то заметной деградации я не наблюдаю.
300 мбит, это примерно 30 мбайт в секунду. На такой малой загрузке диск сможет неспеша оптимизировать все SMR ленты и еще и время останется на кофе с круассаном.
Так что падения производительности никак не должно быть
Так ведь рандомная, а не последовательная запись.
не такая уж и рандомная, если блок 4МБ
Он может быть и 512к, плюс клиент не всегда ждёт полной загрузки при сбросе на диск.
предлагаю еще оключить кеш чтения и записи на HDD, а потом говорить «ну вот, диск не справляется, фигня какая-то, а не диск»
Так ведь размер блока и поведение клиента не от меня зависят. Я ничего специально не отключал, оно само такое.
насколько я знаю торрент-клиентов, то там в самом клиенте можно выставить кеширование блоков, перед сбросом на драйв, у меня в uTorrent например стоит 128МБ.
Установив кеш приличного размера, можно сократить IO диска и уменьшить фрагментацию.
Не знаю уж будет ли клиент пытаться закачивать в кеш линейно или рандомно, но даже 128МБ непрерывной рандомной записи с последующей паузой лучше чем непрервное дерганье диска 512КБ-ми блоками
Для файлопомойки — только если 1 раз записать и потом только читать. Например — скачал торрент на ssd, готовый переместил на smr spinning rust и продолжаешь раздавать. Это единственный рабочий сценарий.

Видеонаблюдение подходит?

Похоже на то.
Единственно что этот не тестировал подобный сетап, но видеонаблюдение как раз про много записи и мало чтения, плюс своя упрощенная ФС.

Всё же стоит быть честными и предупреждать покупателей о неприятных нюансах данной технологии.
Новость и вправду отвратительная.
А какая непрерывная нагрузка в 100 Мб? да простая, домашняя: бэкап на полочку положить. В качалку-раздавалку торрентов поставить. Самые простые кейсы.
А насчёт «явно не предназначены»- об этом производители упомянули или надо догадываться?
Хоть бы немного подробностей для тех, кто не в теме. Что такое SMR, что такое черепичные диски. Да, я могу это нагуглить, но было бы удобнее видеть это сразу.
Долго думал, что еще за cherry-pick'ные диски и причем тут гит?! Автор не смог в написание статьи.
У меня на «сервере» (колхозном) попался подобный (SMR) диск.

Сейчас 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 — их. Например, WD EFRX OK, а EFAX — нет. Появляется все больше свидетельств, что та же буковка A у синих WD тоже означает проблему www.reddit.com/r/DataHoarder/comments/g3oxrw/wd_blue_new_2018_line_models_explained_smr_greens
image

Показатель весьма косвенный. Однозначно наличие smr определяет поддержка trim.

Не всегда определяет. К примеру, Seagate Archive не поддерживают trim/discard, хотя очень даже SMR.

Вероятно, вышло несколько неоднозначно.
Каджит хотел сказать, что если жесткий диск поддерживает trim/discard/unmap, то он точно smr, потому что больше никому такое не надо.
Но, да, технически smr-диск не обязан поддерживать trim.


Однако, в отличие от размера кэша, поддержка trim однозначно говорит, что диск отличается от обычного.

у WD классически весь секрет в цифирках после номера модели.
Условно WD10EZEX-08WN4A0 может быть одним типом накопителя, а -22BN5A0


Извините, что капитаню, но я с WD наелся уже. Даже Сигейт идентифицировать всегда было проще друг от друга (по полной модели STxxxxxxxxx).
Проблема лишь в том, что вот эту полную модель получить никоим образом нельзя из оф доки wd, а приходится экспериментально считывать из паспорта накопителя и соотносить с параметрами на опыте

Про 8 ТБ данные есть? Там везде 256 МБ кэша у WD, а по стоимости 1х8 почти равен 2х4.
для начала стоит знать, что WD не делает 8ТБ диски (пока), 8ТБ и выше, это диски HGST с наклейкой WD.
Соответственно стоит пойти на сайт Хитачи и почитать про их модели, какие с СМР, а какие нет.
Но имейте ввиду, WD по умолчанию поддерживают multi-stream, т.е. при записи/чтении в 2-3 потока, скорость диска равномерно размажется между этими потоками.
А у Хитачей в таком режиме производительности прихрамывает (у не-eneterprise Сигейтов вообще отсутствует)

А если напрямую у производителя запросить инфу перед покупкой, они ответят? По идее они о своей продукции обязаны разъяснить ВСЕ ттх. А если не верно ответят (соврут), могу я потом забрать свои деньги и вернуть диск?

Третья буква у WD обозначает обороты (5400) и размер кэша (256Мб), но это не означает, что в какой-нибудь премиум-HDD без SMR они не запихнут 256Мб кэша
Производители HDD роют могилу HDD. Раньше одним из поводов купить HDD была как раз абсолютная предсказуемость скорости чтения-записи и времени доступа, так как для SSD это всё сильно зависит от типа памяти, контроллера, сценариев использования… Так что не смотря на прорывное развитие SSD, HDD до сих пор оставались проверенным, надёжным стандартом, да ещё и с копеечной ценой за гигабайт. А тут нате вам, HDD ещё немного дешевле, но уже гораздо менее надёжные, причём об этом не заявляется явно. В общем поди угадай, что тебе там продадут. В итоге один из двух аргументов в пользу HDD сводится на нет, и остаётся единственный — дешевизна. Посмотрим, на сколько его хватит…

Так НЖМД уйдут в нишу магнитной ленты, став накопителями с затруднённой случайной записью. Да и то, лента выигрывает в энергоэффективности, что для архива критично.

У нас нет других накопителей способных в выключенном состоянии сохранять информацию.

Я думаю, это повод поднять цены. Думаю, через некоторое время цена SMR дисков повысится совсем незначительно, а вот не SMR будут гордо маркировать огромной надписью и задерут ценник до небес. Маркетинг… "хлопья_без_асбеста.jpg"

А потом в какой-то момент обнаружится, что они «изобрели» совершенно уникальную™ технологию, которую назвали Layered Magnetic Recording, и эти сверх-дорогие диски, действительно, никакого SMR не содержат, а содержат только этот LMR.
Повторим путь «Матовые экраны» -> «Супер дупер крутые глянцевые» -> Вас задолбало своё отражение в экране: «Купите ноутбук с новой матовой матрицей!!!!»
Вас задолбало своё отражение в экране: «Купите ноутбук с новой матовой матрицей!!!!»

только за x3 денег

Извините, но так и не уловил смысл этой черепичной записи. В чем смысл записи более широкой чем для чтения головкой? Или запись более узкой головкой физически невозможна? Или её нельзя так точно спозиционировать?

Ну да, примерно так, что надёжно записать более узкой головкой не получается.

Смысл на пальцах в том, что когда пишешь воздействие сильнее. Поэтому воздействие «растекается» и дорожка оказывается шире. Когда читаешь — уже. При SMR дорожки записи накладывают частично, как черепицу, собирая в ленты. В результате произвольное чтение возможно, а запись — только всей ленты. Чтобы не было катастрофы по скорости производитель устраивает на блине и зоны нормальной (CMR) записи, которая используется как кэш второго уровня (первый — память диска) при случайной записи. И опустошается при простое диска.
Или запись более узкой головкой физически невозможна?
Да. Дело уже не в головке, а в конфигурации магнитных полей, они так просто не хотят делаться у́же.
Дополню уже имеющиеся ответы

Смысл примерно такой же, как с 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.


Не говоря уже о повышенной нагрузке на механику диска.


Учитывая, что статистически ожидаемая вероятность ошибки для консьюмерских дисков уже не позволяет считать объем диска без нескорректированых ошибок…
При этом ничто не мешает им притворятся почти нормальными, особенно, пока диск почти пуст.

Спасибо большое всем за ответы. Что-то технология выглядит совсем «не очень». Эти ухищрения сделаны только для очень больших дисков, или для всех подряд, вроде 1-2Tb?
Что-то технология выглядит совсем «не очень»

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


Ухищрения, к сожалению, уже практически везде. Лучше мониторить форумы вроде ixbt, чтобы не ошибиться. Как косвенный параметр, можно ориентироваться на цену. Если два абсолютно одинаковых диска отличаются в цене на четверть, то есть вероятность что более дешовый как раз с smr.

Прошу прощения за оффтоп, но уж больно интересно — почему Каджит говорит о себе в третьем лице?

И, таки да!

Плотность в 1Тб на блин 3.5" HDD достигнута уже давно, так что в терабайтных моделях такое вряд-ли возможно будет встретить. А вот 2Тб уже, судя по всему, есть с SMR (WD20EZAZ например). Проще всего смотреть на кеш и вес в сравнении с схожими дисками — если вес сильно отличается в меньшую сторону по сравнению с аналогичной моделью, а кеш в разы больше — скорее всего перед вами диск с SMR
Ещё есть такой момент, как потенциальное снижение ресурса накопителя при черепичной записи. Перезапись нескольких дорожек при работе с одной это бОльшая нагрузка на механику по сравнению с перепендикулярной записью. Интересно, как это сказывается на ресурсе?
Насчёт бОльшей головки записи — как я понимаю, достигнут предел сегодняшних технологий для обеспечения надёжной записи при растущей её плотности. Поэтому в виде черепичной записи нашли ресурс для дальнейшего повышения плотности записи, но ценой производительности накопителя.
Похоже, что лучшее применение таких винчестеров это «холодные» данные и задачи, где случайная запись сведена к минимуму, например видеорегистраторы и в стандартных задачах их стоит избегать.
Перезапись нескольких дорожек при работе с одной это бОльшая нагрузка на механику по сравнению с перепендикулярной записью. Интересно, как это сказывается на ресурсе?

Но меньше блинов, и, соответственно, БМГ легче. Так что задача становится вдвойне интереснее.

Выглядит как бага в фирмвари. Какая разница откуда читать?

Не читать, а писа́ть.

"где запрос на проверку сектора, в который еще не был записан вызывает ошибку" звучит для меня как чтение, а не как запись.


В проблему я сам не всматривался, но по посту это выглядит как ошибка чтения из незаписанных данных.

Ну да, ничто не должно мешать отдать данные из кеша.

Интересно, а диски, наполненные гелием, такой болезнью страдать не должны? Или кто-то уже совместил две этих убийственных технологии?

WD снова отличилась.

Да лучше прям как во время DTLA/DDYS/AVER — стеклянные блины, а чо — модно. Представляете себе убийственное сочетание? Гелий, стекло, SMR! И еще крышечку прозрачную


Вот так https://festima.ru/docs/182495250/moscow/hdd-wd-raptor-x-wd1500ahfd-150gb-bu-redkiy

Ээээ… хитачи разве не до конца производили стеклянные блины?
Но даже если нет, проблемы тех винтов не в блинах были, а во флюсе.
Да и если диск не пинать, стекло не крошится, а если пинать — то диск не жилец.

Нет, со флюсом (это общеизвестно) — проблемы были у фуджей. Cirrus logic и все такое. После серии mpg им пришлось уйти с рынка десктопных накопителей. Но вот ноутбучные и серверные они ещё очень долго делали и они были прекрасны. Пока их не купила вроде бы Хитачи.
А с айбиемками там вообще интересная история была. Реальная катастрофа из-за неудачного стечения обстоятельств. Начиная от багов в фирмваре, неудачном игольчатым контакте между гермоблоком и контроллером (лечилось простой пропайкой), да ещё и стеклянные блины, с которых магнитное покрытие слезало. Жесть, короче.

Да, спутал. Спасибо, что поправили.

у AVER-ов разве со стеклянными блинами проблемы были?
мне казалось, там что-то с механикой, то ли головки, то ли шпиндель

у DDYS — точно, у AVERов могли и к металлическим вернуться, но они более надежными от этого не стали. Не помню — давно было

Назад в будущее к магнитной ленте¿

Я вообще не понял проблемы. Мне вообще по барабану, что там внутри 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

Оно вообще непонятно как измеряется.

То есть они вот так взяли и похоронили одно из важных преимуществ HDD перед SSD? Теперь HDD тоже стирают только большими блоками, что то там самостоятельно внутри себя перезаписывают… И только ради возможности поставить 3 блина, а не 4?

Ага. Только у хдд все ещё остаётся преимущество — их можно писать, класть на полку и, условно, через год данные там останутся. На ssd, была недавно тут на Хабре статья, Флэш память теряет данные, т.к. стекает заряд (фейспалм)

У меня SSD лежал не включаясь ~5 лет, я не сравнивал по CRC, но винда с него впоследствии загрузилась. С другой стороны, во время моего сисадминства были пару раз случаи, когда пролежавший в шкафу пару тройку лет HDD не раскручивался. Можно конечно считать, что данные на блинах остались, но ценник на аппаратное восстановление негуманен.

Типичная иллюстрация принципа, что бекап нужно регулярно проверять, иначе это не бекап

Стратегия создания бакапов выходит за тему статьи, я лишь хотел сказать, что для целей длительного хранения больших массивов информации ни одна доступная технология не подходит. То есть мы можем сказать про прошлое, что вот эти HDD или эти DVD-R стабильно хранили информацию 10 лет, но сейчас точно таких купить нельзя, а сколько смогут хранить те которые купить можно, станет ясно через 10 лет (или раньше, если все плохо). Пока, наибольшей стабильностью отличаются магнитные ленты, но и тут в новых технологиях нельзя быть уверенным (более высокая плотность записи рано или поздно приведет к снижению срока хранения).
эти DVD-R стабильно хранили информацию 10 лет

к сожалению, у меня с ними негативный опыт


а сколько смогут хранить те которые купить можно, станет ясно через 10 лет (или раньше, если все плохо).

соглашусь


Пока, наибольшей стабильностью отличаются магнитные ленты, но и тут в новых технологиях нельзя быть уверенным (более высокая плотность записи рано или поздно приведет к снижению срока хранения).

еще вариант — облако, и побольше копий (вопрос только лишь в том, что это реально может стать дорого)

DVD перестают читаться из-за деградации рабочего слоя под воздействием влаги и кислорода, что тоже нивелируется условиями хранения, правда, уже несколько сложнее
для целей длительного хранения больших массивов информации ни одна доступная технология не подходит

Магнитная лента. Стоит меньше, не требует электроэнергии при хранении, хранится десятилетиями.
Вот вам пример: нашел кассеты (dds) со старыми архивами примерно 15-летней давности, купил стример. Все кассеты успешно прочитались.
Вы уверены что прочтете кассету LTO-8 через 15 лет?

Да и купить исправный стример двадцатилетней давности может быть непросто, там механика и резина подвержены естественному старению.
Вы уверены что прочтете кассету LTO-8 через 15 лет?


Не уверен, да и как тут можно быть уверенным на 100%? Но есть положительные примеры. Например вполне реально найти живые стримеры LTO1, например, а ведь с момента создания прошло 20 лет. К тому же чтобы прочитать кассету LTO1 нужен стример 1, 2 или 3 поколения, их живых полно. Да и более старые вполне себе живут.
А чтобы прочитать LTO8 нужен будет привод 8-10 поколений, если будет сохраняться стратегия обратной совместимости.

Другой вопрос, что сейчас LTO8 очень дорог, не для дома однозначно. Зато 4-5 поколение можно найти за вменяемые деньги. Под архив сериалов — самое то))
Навскидку, на вторичном рынке, цена гигабайта ленты LTO4 сравнима с 2.5" HDD, набор привод + контроллер сравним по цене с самосборным сервером.

p.s. Возможно, используя диск восстановления windows10 восстановить систему с ленты?
Я несколько лет назад брал поиграться LTO-4, описывал тут USD260 обошелся SAS привод, сейчас за эти деньги LTO-5, думаю, можно найти. Кассеты в Москве нашел по 200 руб за штуку (сли много брать), по одному разу записанные.
Как счастливый обладатель стримера LTO-5, могу добавить, брал в этом году привод HP в пределах 25-30 тысяч рублей с пробегом менее 6 тыс. км (эквивалентно 91 полностью записанной ленте). Состояние всех узлов, согласно диагностической утилите 98-99%.
Не знаю, сматывают ли пробег у стримеров, по внешним признакам, выглядел он вполне неплохо.
SAS контроллер в самосборном NAS — вещь, зачастую полезная и необходимая сама по себе, да и стоимость умеренно старого SAS HBA не то чтобы очень велика.
Скорее проблемой будет нормально охладить всё это железо, и стримеру и HBA очень желательна принудительная вентиляция.

С другой стороны, учитывая специфику работы с лентами, думаю, далеко не всякому подобное устройство будет полезно, хотя поддержка LTFS может сделать их гораздо полезнее для обычного пользователя.
С LTFS пока не игрался, FreeBSD поддерживает её только для приводов IBM.

Насчёт диска восстановления. У HP есть какое-то ПО, позволяющее восстановить систему непосредственно с ленты, честно говоря, не интересовался этим вопросом, как и вопросом, как не покупая новый стример стать счастливым обладателем лицензии на это ПО.

Поскольку этот вопрос мне наверняка зададут, отвечу сразу, использую ленты для периодической архивации бэкапов и как средство резервного копирования, если больше записать некуда (например, при реорганизации хранилища под бэкапы), кроме того, лента бывает полезна для всяких архивов из категории «удалить жалко, хранить негде». Лентам я доверяю не больше чем жёстким дискам и прочим носителям информации, всё важное хранится строго в нескольких экземплярах и на лентах и на дисках одновременно.
Нет. И еще стример кофе не варит…
Disaster recovery — немного другая задача, но восстановить с ленты на голое железо могут продукты Acronis(версию сейчас не вспомню) и вроде бы Veeam (не пробовал). Не реклама, если что.
и вывод был в этой статье, что флэшки надо хранить в холодильнике, тогда там десятки лет заряд сохраняется
Собственно и про CD/DVD такое говорили, меньше температура — меньше диффузия и химические изменения. Предположительно и ленте низкие температуры полезны. Остается вопрос извлечения и применения, логично хранить в пакетике с силикагелем, а извлекать из пакета уже при комнатной температуре.
вакуумные пакеты должны быть норм
Какая современная тестовая программа для дисков, покажет, что диск с SMR?
Алгоритм при покупке стандартный.
Через интернет-магазин обязательно.
После покупки тестируешь диск и в случае SMR, возвращаешь обратно.
С причиной «цвет диска не гармоничен с цветом моего системного блока».
Впрочем можно обьяснить и реальную причину.
Очень просто, пока. Смотрим размер кэша. 32-64 это нормальный диск 1-2 тера, 64 — норма для более ёмких. 256 просто так не положат. Табличка была выше, khajiit проиллюстрировал.

Если речь об этой табличке, то ее принес сам автор поста, каджит просто откомментировал.

Аналогично и на 3 Тб было написано
image

PastorGL программа есть на офф.сайте WD, но тот что слева на картинке — щёлкать не перестал.

слева на картинке слишком уж древний. для такого можно поискать в интернетах утилиту "wdidle3", она меняет только интервал парковки. но аккуратно, может убить его насмерть.

Писали, что поддержка диском команды TRIM однозначно идентифицирует SMR.

Можно пояснить — зачем диску TRIM? И как это взаимосвязано с SMR? Или диски стали настолько умны, что LBA сектор (который снаружи виден операционке) уже вообще никаким образом не связан с физическим сектором на блинах? Ну, примерно как уже в SSD сделано (но там на это хотя бы есть физические причины из-за особенностей страничного хранения данных во флэш памяти)

Я это понял именно так. В SMR HDD все данные разбиты на группы дорожек которые пишутся/читаются одной головкой. Грубо говоря, промежуток, серводорожка за которую цепляется головка, несколько дорожек данных записываемых единомоментно, промежуток и так далее. Примерно как многополосное шоссе. По команде TRIM диск помечает (а может и стирает, я не уверен) такое многополосное шоссе пустым. LBA кстати говоря, уже давно не связан с физическим местом на блинах, диски прозрачно для пользователя переназначают сектора которые физически неустойчивые.

Кстати говоря, следствие всего этого — ждем багов в фирмваре 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

О, usb-hdd )
Да, чистые 4096 тоже есть. Правда, живьем видеть не доводилось.

Позвольте позанудствовать. Бывают ещё крайне забавные диски с размером блока в 520 байт. EMC очень любила таким баловаться, например. Говорят, ещё 528 бывают.

внимательно слушает и записывает, потому как шанс самому увидеть это железо очень наврядли представится

Бывают ещё крайне забавные диски с размером блока в 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 — бытовуху не самого лучшего качества продавать по цене энтерпрайза от других производителей, и даже своего (HGST)
ну справедливости ради стоит сказать что WD Red это диски WD, а WD Red PRO это диски HGST с наклейкой WD
WD RED pro 8TB ~360$
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/knowledgebase/DSM/tutorial/Storage/PMR_SMR_hard_disk_drives

Интересно, я это пропустил, когда выбирал диски себе или же этой информации не было? Вангую что второе…
Да, опечатался. EFAX с SMR. Спасибо за замечание.

Как занятно это всё. Для чего же ещё сейчас покупать hdd обычному человеку (т е не Энтерпрайз и не на работу) если не в качестве домашнего хранилища? По-моему они решили самоубиться....

Они решили снять сливки с медленно умирающего рынка шпиндельных накопителей....

это медленное умирание еще лет на 10 растянется, а то и больше
40-50ТБ ССД за $200 нам еще долго не видать, а HDD такие уже в этом году могут пойти
Ох, помню я, в самом начале двухтысячных годов так же говорили про CRT мониторы, что LCD их никогда не заменят, ведь у LCD время отклика хуже, разрешение всего одно фиксированное, да и цветопередача не очень… Ну как-то потребительский рынок с этим справился, CRT ушли в анналы истории буквально за 5 лет, не смотря на сохранившиеся отдельные преимущества по сравнению с LCD.
Так и тут, достаточно просто сделать 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
А ленты все живут и развиваются

и продажи всё падают? )

Автору спасибо! Вовремя заметил статью, как раз планировал купить пару дисков в NAS.
Теперь придется выбирать диски более тщательно.

Я выложу потом программу для определения 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.

Да, это как раз логично, ну, до некоторого предела. Неважно какой у тебя кеш, если он меньше 100% все равно его можно отравить и подобрать худшую возможную нагрузку для него.

И да, и нет. Все очень сильно зависит от того какой алгоритм внутри прошивки. Условно — ну, показали бы вам 128 МБ кэша из 256МБ, а остальное — чисто под какие-то внутренние оптимизации. Стало бы легче пользователю от этого ?

Я не про показывание. Я про то, что всегда есть способ нагрузить любой кеш в такой форме, что кеш не поможет и мы упрёмся в реальные latency.
Но да, если кеш в состоянии съесть и прожевать весь I/O то это невозможно, так как это уже что-то больше по размеру чем сам диск.

Там кэш не для чтения используется, а для записи, это совсем разные вещи. Хотя в реальных дисках, которые были у меня, были жёсткие ограничения на количество записей в кэше, таким образом, если ты пишешь одновременно большие записи и маленькие, кэш мог заполниться лишь на небольшую часть, что ещё больше уменьшает скорость (скорость условно пропорциональна размеру кэша до тех пор, пока не упрётся в скорость чтения непоследовательных блоков с кэша + скорость линейного чтения с SMR-блоков + скорость линейной записи в SMR-блоки + IOPS на запись расположения новых блоков (которые всегда кладутся в кэш; вероятно, 1 IOPS на блок) + скорость непоследовательной записи новых блоков в кэш).


Если пишем линейно, чтение и запись в кэш, вероятно, могут не требоваться, данные могут взяться напрямую с ОЗУ. Если кэш SSD SLC, а не HDD PMR, операции с кэшом будут почти бесплатные (что юзается в реальности, я пока не тестил), но такой кэш очень дорог + подвержен износу. Теоретически SLC кэш может юзаться, чтобы не уничтожить данные во всём SMR-блоке во время записи в случае отключения питания, но это ещё больше усиливает износ.


Но это всё очень примерно, т. к. пишу по памяти или вообще что-то ещё не проверял или додумал прямо сейчас, поэтому с огромной вероятностью я в чём-то ошибаюсь или пишу неверно. В статье я уже буду точнее писать, а пока меня не стоит воспринимать слишком серьёзно.

ну да, кеш можно использовать по разному. :) и сломать тоже по-разному.
кеш вообще это минное поле…
Интересно, а можно ли заюзать черепицу на дискетах? Чтоб вместо 2.8Мб получить 3.5?
Нет, нельзя.
В дискетах шаговый двигатель, а не адаптивный поиск дорожки.
Помнится, был у меня в глубокой студенческой юности комп с флоповодом, который умел писать аж ДВЕ лишние дорожки на трехдюймовой дискете. Я, будучи молодым и непуганым остолопом, записал на них по 1.7 (или 1.8?) мб архивов рар. Исходники, то-сё.
Естественно, комп я потом кому-то продал вместе с магическим флопарем.
И естественно, ни один из имевшихся в округе флопарей не смог прочесть 82-ю дорожку.
Куча остолопских архивов немножечко пропала. :)
Помню, были утилиты включающие микрошаг и удваивали дорожки — вместо 1457664 получалось 2.88м вот только не помню, были ли попытки использовать еще меньший — по-моему уже на 2.88 обычные дискеты при перезаписи начинали глючить…
В большинстве дисководов на обмотку шагового двигателя можно было либо подать напряжение, либо не подать (может в последних чего и было). Полушаг тут получается подачей напряжения сразу на две обмотки, а вот более мелкие шаги так не получить.
И я сомневаюсь, что драйвера именно удваивали дорожки — проще разогнать контроллер по частоте и писать больше секторов на дорожку, как делал незабвенный 1600.com
Мне смутно помнится, что он не контроллер разгонял, а менял размер сектора на более длинный (2Кб, например). На дискете между секторами предусмотрены довольно широкие зазоры, чтобы можно было без проблем перезаписывать один сектор на дорожке, и за счет длинных секторов эти потери уменьшались. Дискета вмещала бы 2 Мб, если бы не эти потери на межсекторные промежутки (плюс «хвост» в конце каждой дорожки).
Кстати, можно было при форматировании задавать размеры каждого сектора отдельно, чем и пользовались какие-то совсем уж экзотические драйвера.
Ну вот, собственно и ответ на исходный вопрос — можно ли заюзать черепицу на дискетах?
Можно. Сектор сделать размером с дорожку. + и — черепичных дисков, но без собственно перекрытия дорожек
Нет.
Длинные сектора на дискете — это аналог AF-дисков (advanced format c 4-кб секторами). И кстати, на дискете не получится использовать сектор длиной во всю дорожку (не помню, почему — то ли ограничения на размер сектора в контроллере, то ли ошибки чтения вылезут).
Черепичная запись — это когда за счет частичного наложения дорожек растет их количество на диске. На дискетах это работать не будет хотя бы потому, что головка чтения там широкая и при частичном наложении дорожек будет читать две-три дороги сразу — т.е. шум.
www.frolov-lib.ru/books/bsp/v10/ch1_21.htm — я таки ошибся, 1600 — это объём диска. Тот драйвер таки увеличивал число секторов на дорожке, но назывался по-другому.
Спустя пару дней после шума на счет SMR в WD спохватились и написали пост от 20.04.2020, якобы пользователям не надо думать о том что и как там под капотом работает.
Резюмируя — «ешьте что дают».
blog.westerndigital.com/wd-red-nas-drives
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.