Hard Помогите с выбором жесткого диска

Большой блок брался для увеличения скорости записи. Тестирование в фоновом режиме и явно не развивается максимум IO/s, на который способен SSD. Можно в принципе сделать ещё двухчасовой проход с выставлением 4к.

--- добавлено 30 июн 2024, предыдущее сообщение размещено: 30 июн 2024 ---

Там по 2 прогона. С 1Гб и с 64Гб.

 

Тест с записями по 4к.
Никакой зависимости не прослеживается. Просадки связаны с тем, что это рабочая система, а не тестовый стенд. Из определяемых нагрузок - просадка до примерно 200Гб. В этот момент у меня шло активное копирование нескольких сотен Гб. Остальные просадки не соответствуют нагрузкам, которые я отмечал (забыл выключить uTorrent - момента его отключения не видно на графике, запускал 7z и WinRar с большими словарями, отработали в сумме несколько минут - тоже нет ничего). Имеющиеся просадки скорее всего связаны с шебуршанием кошмарыча.

Итого, SSD из серии MX500 сейчас можно взять для XPшной ретросистемы. Будет просто ультимативно быстро для XP. Но дорого. Желательно не спускаться ниже 500Гб, там устоявшаяся линейная запись около 300Мб/с, у 250Гб может быть 150Мб/с (речь о текущем, довольно быстром TLC B47R флеше).

 

Поддержка блочных, а не посекторных, операций у контроллеров и биосов получили массовое распространение ещё во времена 486-х. Размер кластера файловой системы 4 КБ совсем не означает, что все операции происходят только по 4 КБ за одну АТА-команду. Совсем наоборот - драйвера XP, как и большинство софта, оптимизируют отдаваемые запросы на чтение и запись в зависимости от настроек политики кэширования и объёма запросов со стороны ядра. При увеличении размера файла или просто даже объёма читаемого из файла размер блоков в операциях увеличивается сам, без вмешательства пользователя. Если же пользовательский софт (бенчмарк?) просит конкретно по 4 КБ за операцию, то дальше оптимизировать очередь запросов и собирать их в блоки будет уже контроллер самого диска.

 

В рамках теста всё же имелась ввиду иммитация работы с БД, когда в созданном большом файле перезаписываются блоки в случайных местах. Так что блочная запись там всё же не сильно спасёт, наверное.
Я увеличил размер блоков так как на моей системе в фоновом режиме не вытягивается максимальная скорость случайной записи блоками по 4к для этого SSD. Хотел ориентироваться не на ограниченное задачами IOps, а на скорость записи во флеш, что больше всё же рассказало бы о SSD, чем о моей системе.

Самый важный результат теста - текущий Crucial MX500 на 2Тб от отсутствия TRIM не страдает. Есть обоснованная надежда, что и модели на 250-500Гб будут работать в такий ситуации не сильно хуже.

 

@TheMadLynx,
Ещё раз:
в системе на XP не будет операций на 1МБ за раз. Исключение - последовательная запись данных.

Дело не в размере операций на уровне драйвера ФС и ниже, а в том, что никто и ничто тогда даже не думал писать такими объёмам. Максимум - 256КБ, и то - редко и в очень специфичных случаях, явно не применимых к домешнему компу для HOMM погонять.

Поэтому рассматривать производительность SSD в конктесте WinXP записями в 1МБ не имеет смысла.

 

Взаимоисключающие (самоопровержение?) параграфы получаются. Типа если игра грузит сохранение больше 256 КБ - XP не даст это сделать ей за раз?

 

Crucial BX500, 500Гб.
Из чего состоит мой экземпляр и как линейно пишет/читает:
Hard - Помогите с выбором жесткого диска

Этот диск не жалко, потому на нём честно отрабатываю SE, перезугружаясь в линуксовые LiveCD. Штатными методами под виндой не даётся, говорит, что заблокирован. Передёрг питания не помогает.

CrystalDiskMark даёт интересные результаты на первом же тесте. Разница между тестовым набором в 1Гб и 64Гб разительная. С лёгкостью исчерпываем вторым вариантом SLC кэш и видим падение производительности ещё до записи 1.5Тб данных.

При записи поначалу диск был хорош, но после 10% свалился. Сначала шёл около 50Мб/с, довольно стабильно. Потом пошли качели 40-60Мб/с, с некоторыми просадками до 15-20Мб/с. Писал я уже кучу видео разного размера, как фильмы так и ролики, почти без мелочи. Потому как удалять сотни тысяч файлов - это такое себе удовольствие оказалось по опыту с МХ500. При заполнении обнаружились странности на моей системе. Для сброса бэкапов на пары HDD, которые потом лежат себе "на полке" использую USB3.0 докстанцию AgeStar 3UBT8, очень удобная штука, которая позволяет работать сразу с парой SATA HDD 3.5"/2.5". Но при сбросе архива увидел, что скорости работы ушли куда-то в район 5-20Мб/с на обоих дисках. Хотя диск, с которого сбрасывал, сильно быстрее любого из пары этих архивных. Да и ранее одновременная работа обеспечивала 60-80Мб/с, что не на много ниже максимумов этой пары. Проверил смарты всех трёх дисков, участвовавших в процессе - всё в норме, перекинул док на другой разъём (2-й набортный контроллер, мало ли первый свалился в USB 2.0) - нет изменений. Подключил старый AgeStar 3FBCP1 - он протягивает через себя около 100Мб/с - тоже низкие скорости. По итогу случайно заметил, что проблемы начинаются после того, как BX500 сваливается в свои 40-60Мб/с. Причём независимо, на набортном контроллере он висит, или на ASM1064. Странная ситуация всплыла на моём зоопарке.

После нагрузки всё погрустнело...


30 минут отдых



TRIM


Результаты теста выглядят грустно и не совсем логично, но как есть.

Ради интереса добавил ATTO Disk Benchmark.

По записи пик по IO на 2кб, плато по скорости начинается с 512кб.

Соответственно, проведу первичное тестирование в IOMeter в 2 захода, сначала на максимальную скорость, потом на 4кб секторах.

5.6Гб пишется быстро. Затем начинается этап с большей частью точек в районе 50Мб/с, который идёт до примерно 48Гб, т.е, длится около 42Гб. И за ним до самого конца идёт участок, где основное количество точек находится в районе 27-31Мб/с. Но приглядимся к линии тренда, которая строится с округлением нескольких близлежащих точек, что значительно лучше показывает среднюю скорость. Тест отдавал в лог данные примерно ежесекундно. В диаграмме выше берётся 13 точек для линии тренда, чтобы совсем не потерять в линии очень быстро завершившийся участок SLC кэша. Выглядит как ёжик, но где её основная часть? Следующая диаграмма - с округлением по 18 точек.

Опа... Так 2-й участок то оказывается медленнее 3-го! Хоть подавляющая часть точек находится на нижней границе, но реальная скорость записи растёт весь 2-й участок примерно от 50Мб/с до 75Мб/с. После чего примерно на этот уровне и держится всё остальное время. Похоже, сначала у нас идёт запись в SLC кэш, поток кэш заканчивается и его надо разгребать - получаем первую ступеньку, но после разгребания, в основном ведём прямую запись в флеш, SLC кэш при этом как-то хитно используется, и не смотря на основную часть записи на малых скоростях 27-31Мб/с, имеется достаточно пиков вплоть до максимальной скорости, чтобы вытянуть среднюю до примерно 74-75Мб/с!
Очень неплохо для дешманского QLC накопителя и в целом многовато для такой конфигурации QLC флеша. Данные кидаются медленнее обычно. Возможно, IOMeter творит что-то не то в случайной записи.

Теперь те же условия, но запись 4к. Предварительно сделал SE.

Быстро пишем примерно 2.5Гб, потом небольшие ёрзанья до 14Гб, потом опять быстрая запись где-то до 21.5Гб и далее расчёска. Правда, стоит понимать, что "быстро" это примерно 110Мб/с с пиками до 120Мб/с.
Видимо, настолько не справляется контроллер с мелкоблочной записью, что флеш оказываеся не сильно забит и почти не заметен эффект разгребания SLC кэша.
Расчёска довольно интересная. На массиве данных она видна и без графика. 13-15 точек (чуть больше чем по 1с между ними) пишется на скоростях 80-120Мб/с, потом 15-20 точек пишется на скоростях 12-25Мб/с. И такой патерн постоянно повторяется. На линии тренда это не совсем понятно, так как ось X диаграммы не время, а записанные Гб, соответственно, медленные участки на нём выглядят сжатыми.
Если для скользящего округления дать бОльшие отрезки (по 37 точек), то выйдет так:

SSD основную свою часть пишет на средних скоростях 60-70Мб/с. Это 4кб блоками. Странно всё это...

Далее то, ради чего всё затевалось. Наглядный сводный график, чтоб понять, как SSD будет отрабатывает в среде без TRIM, как в статье.

И...
В целом ХЗ что сказать. Вроде бы сборщик мусора что-то разгребает и каждый раз есть стартовый SLC кэш примерно около 1%. В том числе и для условий свежего SSD. Что странно. SLC кэш должен быть около 7-8%. Перед первым тестированием IOMeter создаёт файл на десятки гигабайт. Вероятно, это не позволяет показать работу свежего SSD с файловой системой. Но при этом не происходит восстановления до нулевого состояния после TRIM.
При тестах без файловой системы, не происходит восстановление производительности после простоя, хотя в первом прогоне в наличии 7-8% SLC кэша.

Где-то я накосячил с тестами. Погоняю его ещё на ASM1064, который не пропускает TRIM с родными драйверами.

--- добавлено 19 июл 2024, предыдущее сообщение размещено: 19 июл 2024 ---

По производительности для XP ретросистемы пока выглядит достаточно хорошо. В подавляющем большинстве случаев в медленную запись упираться не придётся. Особенно, если оставить для сборщика мусора большой неразмеченный запас.
Но беспокоит время жизни не обновляемых данных в QLC флеше. Ретросистему собрал, настроил, поигрался и потом она год и больше может стоять себе без включения. Заработает ли она потом? Да и в целом, не глядя на включённое/выключенное состояние, не обновляемые данные деградируют со временем. Насколько быстро это будет происходить тут - ХЗ. Бороться с этим просто - снять образ диска, провести SE, восстановить всё из образа. Но как часто придётся такое ТО делать на BX500?
Про ресурс перезаписи, думаю, можно не беспокоиться, его XP ретросистеме и с QLC флешем за глаза будет, ИМХО.

 

Даст, но такие операции в общей куче ничтожны, запусти FileMon/ProcMon и ужаснись на каком примитивном уровне находится архитектура ОС и сами приложения в области работы с файлами. Особо одаренные программмисты сохранение могут читать ПОБАЙТНО, через getc(), ОС превратит это в чтение минимальными блоками по размеру кластера или ещё как.

 

Дополнение по BX500. У меня великоваты скорости вышли при рандомной записи в файл размером 20-30Гб, который создаётся перед тестом. Вероятно, из-за многократной случайной перезаписи.
Запись сменил на последовательную и поигрался с размерами занятого пространства.
Запись на диск, забитый полностью, весь размечен и тестовый файл занимает всё пространство.

"Свежего" состояния не будет по сути, так как тест перед снятием показаний прописывает тестовый файл. И при его больших размерах, естественно, SLC кэш на момент записи результатов уже давно съеден. Чистое состояние имеет смысл смотреть в CDM выше.


"Свежий" совсем не свежий, а по сути сразу после полной однократной записи 500Гб. Начало теста, первые 100Гб, остальные куски - по 50Гб. Был пик в 300-400Мб/с на 2с в начале, а дальше... Участки со скоростями по 20Мб/с, по 10Мб/с и меньше. Пики в 100-450Мб/с. В среднем 44Мб/с. По группировке точек видно некоторое изменение в поведении, которое сохранилось до самого конца.
2-й участок - конец первого 3-х часового теста, средняя скорость записи 41Мб/с.
3-й участок - после простоя. Сначала порядка 1Гб быстрой записи, а потом в основном скорости 10-12Мб/с с пиками до 450Мб/с, в среднем быстрее, чем в конце 3-х часового прогона 49,4Мб/с.
4-й участок - после TRIM. Тоже около 1Гб быстрой записи, а потом скорости 10-20Мб/с, как видно по точками графика. Пики чуть ниже и в среднем имеем примерно ту же скорость, что и на 3-м участке, 49,8Мб/с.

Ну и ещё один тест. В нём я разметил 75% SSD и заполнил 60% размеченного (задал размер тестового файла в IOMeter). Этакая симуляция, как он будет себя чувствовать в ретросистеме при наличии запасов.

Трёхчасовой прогон, начала не видно, так как предварительно тест создал 225Гб файл и о SLC кэше думать было уже нечего. Видны какие-то изменения в работе. Разделил участки и привёл среднюю скорость записи на них.

И итоговый график для оценки восстановления после нагрузок.


По итогу ОЧЕНЬ неплохая работа. Ретросистеме производительности в таком состоянии за глаза просто. При работе без TRIM максимум чего будет - получим эффект, как если бы было забито всё размеченное пространство. При резервировании 50-100Гб (я вообще 25% делаю) в любом раскладе 5-12Гб быстрой записи будет в наличии, чего для XP за глаза.
Вот чего плохо - QLC флеш. Ретросистема может стоять по пол года без включений, ну собран у меня тестовый стенд, или подключён другой ретросистемник. Как будет QLC флеш держать запись - вопрос открытый. Как бы не пришлось регулярно сталкиваться с проседаниями скорости чтения и т.д..
Да, это легко решается поддержкой бэкапа на HDD.
Прям картина... Вот захотелось мне чего-то. Вытянул системник, подключил и понял, что ближайшие часы я не играть буду, накатывать бэкап на QLC SSD, предварительно сделав ему SE...
Как-то не очень перспектива для QLC в моих ретросистемах. Хотя по производительности претензий просто никаких...

 

Ну и предварительный скрин первого теста после небольшого финта ушами...

 

Т.е на 2Тб диске остаются неразмеченными около 500Гб?

Это для продления жизни диска делается?

 

Скорее для того, чтобы гарантированно избежать значимых просадок (в рамках возможностей SSD). В целом это так же снизит паразитную перезапись при полном заполнении, что уже даст некоторое продление ресурса. 25% - это просто удобная лично мне перестраховка. В подавляющем большинстве случаев достаточно 10-15%.
В случае ретросистемы это дополнительно облегчит работу сборщика мусора и даст гарантированный остаток, не дав мусору, по которому не пришёл TRIM, съесть всё пустое место. В принципе, с современными SSD и их алгоритмами на старых системах при наличии не размеченного запаса даже можно забивать на TRIM. И это не скажется на производительности, даже если речь о топовой XP системе.

 

Это перебор.
10% выше крыши, а на дисках больше 1Тб - и меньше % можно, и даже нужно, потому что чтобы понадобилась "дырка" в 100Гб, то надо:

а) забить весь раздел
б) записать в этот забитый раздел больше 100Гб

 

А надо именно неразмеченным оставлять, или можно разметить весь доступный объём и не заполнять его более чем на 90 процентов?

Как правильно называется такая фича (резервирование) для ssd?

 

Проще не размечать.
В случае ретросистемы и отсутствии TRIM - обязательно не размечать.

--- добавлено 4 авг 2024, предыдущее сообщение размещено: 4 авг 2024 ---

Зависит от SSD. Выше результаты тестов BX500 до перепрошивки в SLC.
100Гб резерва при полностью забитом размеченном пространстве оставят ему примерно 10-14Гб на SLC кэш.

 

@Kristobal Hozevich Hunta, ssd provisioning - Поиск в Google

 

У 500Гб BX500 это даёт всего около 1Гб быстрой записи при забитом полностью пользовательском пространстве.

 

По BX500 в SLC режиме - проблемный случай у меня.
Поначалу всё круто, полная скорость без ограничений. Но после записи на тестах примерно 800Гб стал вести себя странно. 80Гб пишем очень быстро, а потом расчёска 20-0.5 Мб/с с редкими пиками по 150-200Мб/с.
SE не изменил ситуацию.

 

Напоминает мне разговоры о том, что брызговики на Шахе съедают аж 5км/ч максимальной скорости.

 

А это мне напомнило "640кб хватит всем".