FAQ в помощь строителю "ретрокомпьютера"

Полностью согласен. Зато он хорошо знает что такое сектор, и когда в него что-то пишется, а когда удаляется. Проблема(?) ССД в том, что флэш-микросхемы работают страницами, которые больше чем привычные стандартные 4 кБ сектора большинства файловых систем. ТРИМ нужен лишь для оптимизации процесса удаления информации - ОС отдельной командой сообщает ССД, что секторов удалилось сразу на несколько страниц. Другой функции у ТРИМа нет. ОС не может (и не должна) контролировать, где именно физически и в каких страницах памяти располагаются те или иные сектора файловой системы.

 

Не ошибаетесь, диск понятия не имеет о ФС, единственный способ сказать диску что какая-то область больше не нужна - TRIM

 

Отлично, а теперь вопрос: как же тогда ССД работают без ТРИМа (вообще)?

 

Вы не понимаете как работает файловая система, когда файл не нужен на диске, его сектора с данными никак не обнуляются, вместо этого в "карте секторов"(bitmap) ставятся пометки что сектора не используется. Только эта карта обновляется на диске, ну и в директории очищается запись о файле.

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

Написал ранее на примере sandforce, когда приходит команда на запись произвольной страницы, контроллер именно в этом момент её очищает-перезаписывает, если следующая записываемая страница будет рядом и попадет на другой уровень MLC, контроллер будет ждать сколько положено. Скорость записи на таких контроллерах всегда постоянна и линейна.

 

Вы не понимаете, как контроллер обрабатывает ATA-команды, к которым, в том числе, относится TRIM.

 

Я понимаю как работает контроллер, команду TRIM генерирует код конкретной файловой системы, на пред. странице я дал объяснение зачем нужен trim - фоновая подготовка накопителя к быстрой записи. Нет TRIMa - обычная запись. Надобность такого TRIM желательна обычным накопителям, у необычных может быть сверхбольшой RAM или системная flash область вместо этой RAM, на них с записью могут разные трюки без какого-либо trim, просто потому что реализован отдельный кэш.

 

С этим я как раз не спорю. Более того, по случаю лишний раз полистал стандарт ATA-8, где появился TRIM, и действительно, кроме передачи диапазона адресов, которые драйвер файловой системы считает свободными, больше ничего эта команда с точки зрения разработчика ОС не делает.

Вот с этим спорю. В такой трактовке "необычные" накопители - это почти все современные, у которых контроллер получив команду с указанием диапазона LBA на запись по адресам в диапазоне сам сообразит "на лету", что можно сразу заливать новую информацию в страницу памяти, а не индивидуально переписывать в ней отдельные блоки. Именно поэтому я и писал в начале, что команда ТРИМ лишь позволяет накопителю заранее узнать свободные диапазоны, а не считать их в процессе записи. Ещё раз повторю, если бы не было цирка с поблочной записью на уровне файловой системы, которую нужно согласовать со страничным доступом в микросхему флэша, то и ТРИМ был бы не нужен.

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

Кстати, подумалось, что чем спорить о высоких материях, есть же очень простой и железобетонный способ определить, нужен ли конкретному ССД конкретной модели ТРИМ или нет. Берём накопитель под вопросом и подключаем к компу с ОС, которая заведомо ничего про ТРИМ не знает. Например, WinXP. Пишем данные, заполняем диск, удаляем и повторяем. Возможно, несколько раз для чистоты эксперимента. Перед новой записью даём часок отдохнуть. Если скорость записи при повторных циклах меняется не сильно - значит накопителю нормально и без трима.

 

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

 

Снизу списка почти не восстанавливают, а те что сверху используют скрытые области для перетасовки данных за счет ёмкости накопителя. Запись в страницу flash это две операции, стирание и запись. TRIM мы не дали, так откуда появятся уже готовые стёртые ячейки на самом быстром слое MLC(??) если перед этим мы записали весь пользовательский объем накопителя ?. Иммено из этого кэша, больше не откуда.

 

ЗЫ. Про Win98 и нужность Trim в ней. ИМХО, даже без него на SSD, который ничего не умеет восстанавливать сам, скорость записи будет в худшем случае на уровне немного лучше средних HDD из конца 90-х. Что для системного диска более чем терпимо. При этом скорость чтения (особенно рандомного) всё ещё будет космической для 98.

 

@Mov AX 0xDEAD, выше ведь уже сами писали, что без трима только файловой системе известно, что у нас не весь объём ячеек занят и можно писать по верху страницами, а не поблочно.

То есть объём кэша должен буквально добавиться к объёму основного массива в момент записи без трима, если диск уже заполнен?
SLC-кэш - сущность виртуальная если что и существует на уровне алгоритмов работы с основным массивом в TLC, то есть является частью основного объёма памяти, заявленного производителем. В MLC-накопителях такой фигнёй не заморачивались, там скорость и без этого нормальная.
Зарезервированный скрытый объём ячеек используется для коррекции ошибок и замены сбойных страниц. Плюс то самое "загадочное колдунство", которое восстанавливает скорость записи без трима - объединение подходящих с точки зрения контроллера блоков в единую страницу в фоновом режиме. В качестве кэша резервный объём не используется, так как для этого обычно есть гораздо более быстродействующее ОЗУ.

 

С контролером Promise FastTrak TX2plus SATA150 и SSD Kingston SV300S37A на 120 Гб после перезагрузки Windows 98 на раннем этапе загрузки ОС (до появления графического интерфейса) появляется сообщение о том, что испорчены файлы системного реестра реестра и надо их восстановить. После автоматического восстановления слетает драйвер контроллера (в диспетчере устройств отображается неизвестный SATA-RAID контроллер с восклицательным знаком). Драйвер без проблем устанавливается, потом система даже может нормально загрузиться после перезагрузки. Ещё одна перезагрузка - и снова то же самое. Интересно, это проблема вызвана контроллером (его совместимостью с материнкой на VIA 694T) или SSD-диском? Биос последний. На другой системе с Promise TX4 SATA300 и HDD 500 Гб (Jetway 663AS ULTRA/Athlon XP 2000+) такой проблемы нет. Переставлять местами контроллеры и диски пока не пробовал.

 

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

 

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

В настройках драйвера в устройствах. Или в панели управления.

 

"Железный" Throttle/CpuSpd/FDAPM

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

Конец эпохи, друзья.

 

@Revolter, ага, интересно, каике при этом звуки издаёт питальник проца на плате? Период управляющих импульсов должен быть на пару порядков меньше, чтобы не попадать в диапазон слышимости ухом.

 

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

 

В том смысле, что это вредно для питальника?

Давно замечал, кстати, что при включении "режима торможения" - что на 430VX, что на i815 - на материнке начинает пищать дроссель или что-то такое (но слышно только на очень тихих ПК, конечно). Это тоже оно?

 

@Revolter, интересно, но нужно тестировать.
Сразу вопросы - как будут вести себя демки начала 90-х, заточенные под 286 и 386 (cpuspd не всегда помогает).
И как будут звенеть дроссели в БП и на материнской плате.

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

Мало того, что сами дроссели звенят, так эти наводки проникают в звуковой тракт.