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

Все правильно. И как сюда вписывается совет "пишите диск максимум на треть и он будет в SLC" ?

 

И он в некоторых случаях будет работать на запись как SLC.
Ресурс останется как TLC/QLC.

 

Конечно будет, после того, как утрамбует данные. Его таким образом можно и на 99% записать, что я и делал. Просто не нужно пытаться записать его целиком за раз.

 

Ну, проблемы всё же не только при записи "целиком за раз", но и просто при записи больше, чем конкретно сейчас у контроллера подготовлено места под SLC кэш. И в зависимости от нагрузки и простоев перед этим, работы сборщика мусора, его может быть как много, так и около нуля.
Тут предлагают решение простое, когда некоторые дешманские SSD со своими не самыми лучшими стратегиями будут иметь стабильно большой SLC кэш.

 

@Колючий, это, конечно, дело каждого, но, имхо, лучше просто немного подождать, чем уменьшать объем своего ссд в 3-4 раза

 

facepalm.jpg

Так это и предлагается людям, которым кровь из носу - но надо прям чтоб SSD как SLC работал. Это не предлагается всем подряд в качестве единственно верного пути.

 

Да это обычные хотелки

 

Только в плане скорости записи в случае конкретных стратегий кэширования .применённых производителем.
В плане ресурса ничего не меняется. Он остаётся тем же, относительно полного объёма.

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

Вот дойдут руки, зарежу 500Гб BX500 в 4 раза. Потому что ХОЧУ попробовать так сделать. И если проблем не будет, то восстанавливать его в заводской вид и не буду.
ЗЫ. Если взять 1Тб BX500 и перевести его в SLC режим перепрошивкой, то итоговый ресурс флеша этого 250Гб SSD окажется примерно в 10 раз выше, чем у моего серверного PM883 на 1Тб.

--- добавлено 25 май 2024 ---

Вот честно. Улитимативный бы был SSD, если бы позльзователю свободно разрешили бы менять режим его работы. Пускай с потерей всех данных на переходе. Почему такое ещё никто не предложил - ХЗ... Определённо ведь был бы спрос

 

Там контроллер помрет раньше, чем израсходуется изначальный ресурс.

Вот именно поэтому)

 

Я подозеваю, что у многих дешманских TLC SSD контроллер откинется раньше исчерпания их ресурса по флешу и без подобных трюков.
Но ведь себестоимость не меняется почти, а даёт очень заметное для рекламы преимущество.

 

я именно это и написал

 

А сколько свободного места (в процентах от общей ёмкости) должно быть у SSD для оптимальной работы?

 

@Grue13, предположим, что под оптимальной работой понимается скорость чтения. Тогда сколько угодно.

 

В серверном иногда используют примерно 75% от полного объёма. Чаще 93%. В смысле, диск на 128Гб доступен изначально только как 100Гб SSD ,или из 1Тб доступно 960Гб. В пользовательском это обычно 93%, 97% или 100%.
Это снижение перезаписей при работе сборщика мусора, ускорение его работы и т.д.
Но если речь о дешмании...
Возьмём SSD на бескэшевом контроллере, который всё свободное пространство забивает под SLC кэш, после которого обваливается в запись на скоростях 20-60Мб/с. Раньше так работали все A-Data SU650 (сейчас они работают куда страньше с ещё менее вменяемой стратегией). SSD на 256Гб, TLC кэш. Пустой позволяет быстро записать около 80Гб, после чего сваливается. Заполненный на половину, при нормальной отработке TRIM и нормальной работе сборщика - 40Гб даст записать. При заполнении до 150Гб немного больше 30Гб. 200Гб - 15-18Гб. 220 - 10-12Гб.
Но это в идеале. Реально в процессе эксплуатации SLC кэш будет меньше. Я бы не заполнял его свыше 200Гб.
Это со стороны работы кэша.
Со стороны сборщика мусора - лучше не заполнять его свыше 240Гб. Лично сам везде делаю 75%. Но это скорее оверкилл, который я сознательно выбрал.

 

Почему? Общий объем работ ведь будет тот же, нет? Просто медленнее?

 

Тестирование SSD на надёжность: 3dnews vs JEDEC vs здравый смысл. Где правда, брат?
В разборе ресурсного тестирования 3dnews это рассматривалось с формулами на основе методик JEDEC.

Там, в принципе, есть и график, по которому очень удобно оценить, сколько стоит оставить для резерва в зависимости от конкретного диска с конкретным запасом, к которому пользователь не имеет доступа.

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

Первый (и последний) взгляд на бюджетный NVMe SSD Intel 660p 256 ГБ / HDD, SSD, флешки, прочие носители информации / iXBT Live
Вот кстати попался очередной пример, под который правило "использовать только 1/3, 1/4" не сработает никак. Хотя стратегия та самая гадостная "пишем максимально быстро сколько сможем, а потом страдаем на минимальной скорости".
Есть статический SLC кэш + динамический, который берётся только с половины объёма.

 

Для условно сферического SSD - 10%


И чисто для справки, VERTEX3 за полгода (2023.10 - 2024.05)

Код:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  9 Power_On_Hours_and_Msec 0x0032   064   064   000    Old_age   Always       -       32196h+51m+55.160s
231 SSD_Life_Left           0x0013   092   092   010    Pre-fail  Always       -       1
241 Lifetime_Writes_GiB     0x0032   000   000   000    Old_age   Always       -       12069
242 Lifetime_Reads_GiB      0x0032   000   000   000    Old_age   Always       -       8637

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  9 Power_On_Hours_and_Msec 0x0032   058   058   000    Old_age   Always       -       37429h+59m+51.610s
231 SSD_Life_Left           0x0013   086   086   010    Pre-fail  Always       -       1
241 Lifetime_Writes_GiB     0x0032   000   000   000    Old_age   Always       -       13747
242 Lifetime_Reads_GiB      0x0032   000   000   000    Old_age   Always       -       9800

 

Для лиги лени:
Наработка +5233 часов (218 дней)
Объём записи +1678 ГиБ

1678 / 218 = 7,7 ГиБ/день / 120 ГиБ (официальный объём) = 0,064 DWPD.

Напомню, всякая дешмань имеет 0,304 DWPD (240 ГиБ, TLC) и 0,190 DWPD (120 ГиБ, QLC).

При этом, разница в тысячу рублей (1690 руб за 120 ГиБ vs 2660 руб за 240 ГиБ), при том же DWPD, даёт TBW в два раза больше.

ЗЫ т.е. если бы изначально стоял этот КингСпек, а не Вертекс, то за 37429 часов / 24 = 1559 дней / 365 = 4,2 года было бы записано ~14 ТиБ, т.е. чуть больше половины заявленного TBW (25 ТиБ).
У меня есть основания пологать, что при том же темпе, к 8 годам, когда должен ресурс флеша заканчиваться, либо перестанет хватать места (шутка ли, 120 ГиБ в 2028 году) либо, что более вероятно:
либо сдохнет контроллер самого SSD;
либо сдохнет ноут;
либо древнее говно на i3-4010 (ThinkPad T440) перестанет вообще что-либо тащить, Windows 11-12-14-15 уж точно на него не поставить.

 

Решил подойти обстоятельно к вопросу. Проведу не только тесты записи, но и по примеру Overclockers.ru: Обзор и тестирование SSD-накопителя Transcend SSD340 объемом 256 Гбайт (TS256GSSD340K): интересный середнячок (страница 2) попробую снять стабильность характеристик при наработке (работа сборщика мусора), + у меня в наличии контроллер на ASM1064, который с драйверами от производителя под Win7 не пропускает команду TRIM. Это позволит сэмулировать работу под WinXP.

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


Теперь проверяем по статье.
Secure Erase не производил. Родной софт на моём железе не даёт так сделать. Экспериментировать... При неудаче можно и окирпичить накопитель, а этот мне всё же жалко. Создал раздел на зарезервированном пространстве и провёл в O&O Defrag TRIM по основному и созданному разделам, после чего удалил созданный раздел и расширил основной на весь объём.
Crystall Disk Info
Состояние нового (ради интереса снял на нескольких обёмах тестовых данных).

Трёхкратное заполнение без паузы. Не совсем понял, как именно проводился тест. Заполнение и удаление файлов, так, чтобы суммарной записи вышло на 6Тб... Но на какой итоговой заполненности проводится тестирование? Пускай будет в районе 70%. Т.е. 3 прогона заполнения/освобождения, а на 4-м заполняем диск на 60-80% и без пауз, сразу же, проводим тестирование. После чего диск стоит минут 15-30 и снова тестирование. Потом TRIM по всему разделу и снова тестирование.
Сбрасывал с самсунга 400Гб папку с установленными играми и образами, копируя её в разные папки и удаляя. Скорости стабильно в районе 350-400Мб/с очень красиво смотрелись после моей привычки работать с HDD. Сильные просадки были на папка MAME с десятками тысяч мелких файлов, но не сравнить с просадками на HDD... При удалении же во всю ощутил разницу обычного удаления тотала и ускоренного удаления проводником по Shift+Del (за счёт огромного количества мелких файлов).
Ждут меня ещё дешманские SSD, и будет мне там очень грустно 3 объёма набирать...
Сразу после нагрузки, больших изменений не видно.


Через 30 минут - тоже.


Так как у меня семёрка, то штатно запустить TRIM нет возможности. Только при создании и удалении разделов. Потому для этого воспользовался O&O Defrag.


Результаты... Какая-то фоновая нагрузка влияет куда сильнее, чем меняет своё поведение этот SSD.

Теперь IOMeter.
2 часа случайной записи с очередью в 32 запроса (но большими кусками, по 1Мб), в начале графика состояние нового накопителя, в конце - устаканившегося. Потом 30 минут простоя, проверка работы (10 минут записи с теми же параметрами), TRIM и ещё 10 минут записи с теми же параметрами.
Беглый взгляд на цифры не дал ничего, ощущение, что диск всегда работает в одном режиме. Но решил разобраться с импортом данных в эксель и сделать всё как в статье. Результат оказался интересным.

SSD работает с максимальной скоростью примерно 223Гб, после чего до 945Гб записи есть просадки и потеря порядка 3% скорости записи, далее скорость записи восстановилась почти в первоначальную. Сложно сказать, что это было. Толи SSD сам чего-то разгебал, толи система была занята (тест выполнялся фоново на основном ПК, на диаграмме явно видны периодические шебуршания системы). Вполне вероятно, просадка скорости работы флеша имеется, но в 2Тб модели она не опускается значимо ниже SATA 3 интерфейса.
Работу через 30 минут проверил - ровный график со скоростями около максимальной, не вижу смысла снова ковырять диаграммы ради ровных линий.
В таких условиях задумываться о сборке мусора смысла нет, SSD всё успевает сам и проблем в среде без TRIM быть не должно. А уж в ретросистеме с XP, где скорее всего будет материнка с SATA 1/2...

 

Какой софт, с какими параметрами (1ГБ) - такой и результат.

Так это идеальный режим, нет WA, можно флешить прямо полностью страницами.

Там не будет записей блоками по 1Мб.

ЗЫ, штатно у ХР будет размер кластера на NTFS томе - 4КБ, и при установке поменять не получится (надо до запуска инсталятора).
Увеличение размера кластера до 16КБ или даже до 64КБ крайне положительно (в синтетике, по сравнению с 512/4К) скажется и на производительности и на сборке мусора.