Могу ли я подражать TRIM, записывая все нули?

Question

До того, как сектор SSD ¹ был когда-либо записан, он выглядит как заполненный нулями.

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

Вопрос в том, реализует ли это какой-нибудь контроллер флэш /SSD или что-то подобное?

Это выглядит еще более применимым к флеш-памяти, подключенной через интерфейсы, которые не имеют команды TRIM, например USB.

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

---

¹ _{Логический сектор, то есть то, что видит хост.}

Answer 1

Могу ли я подражать TRIM, записывая все нули?

Нет.
Акт записи требует стирания сектора, а затем происходит фактическая операция записи.
Операция записи указывает SSD, что этот сектор используется (противоположное условие, которое вы хотите получить с помощью настоящей команды TRIM).

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

Неправильно, и, видимо, ваш вопрос основан на этой ошибочной предпосылке.
Стертый сектор заполнен байтами 0xFF (все).

Формат традиционно записывает все нули в каждый сектор.

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

Нет, не будет.
Остерегайтесь наличия "свободных" секторов на уровне файловой системы и "свободных" секторов на уровне SSD. Теоретически они должны быть одинаковыми, но поскольку файловая система должна явно информировать SSD о том, что сектор является "свободным" (с командой TRIM), существуют расхождения.

ДОПОЛНЕНИЕ

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

Вопрос в том, реализует ли это какой-нибудь контроллер флэш /SSD или что-то подобное?

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

В итоге, предложенная вами схема (с использованием данных) не работает.
Если вы хотите обозначить сектор как свободный или неиспользуемый, то есть команда TRIM.
Операции с замещающей записью не существует.

Answer 2

На самом деле стертый сектор SSD заполнен единицами, а не нулями. Вы путаете сектора SSD (фактические физические сектора на SSD, которые мы хотим обрезать) с секторами диска (логические сектора, которые SSD представляет файловой системе после того, как это сделано с помощью магии управления). Заполнение логических секторов нулями не обрезается, поскольку это заставит SSD выделять стертые физические сектора SSD и заполнять их нулями.

Когда логический сектор обрезается, SSD удаляет любые физические сектора, сопоставленные с этим логическим сектором. Когда он получает шанс, он стирает их, что наполняет их 1. После удаления они добавляются в пул стертых физических секторов. Целью обрезки является увеличение пула стертых физических секторов.

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

Смотрите здесь для более подробной информации.

Answer 3

Могу ли я подражать TRIM, записывая все нули?

Нет.

Вот как работает вспышка:

• Незаписанная флэш-память - все 1, и записи сбрасывают 1 к 0.

• Flash записывается в количестве байтов, известном как страница, 2048 байтов являются примером размера страницы. (Существует также небольшой объем данных - 64 байта или около того, который также является частью той страницы, где может храниться информация ECC)

• Что делать, если вы хотите изменить 0 обратно на 1? Вы не можете, если вы не удалите страницу.

• Когда вы стираете флэш-память, которая переворачивает все биты обратно в 1, если страница не повреждена, количество байтов, которые вы можете стереть (размер стираемого блока, заимствованный из терминологии Linux), обычно больше размера страницы. 128 КБ является примером размера стираемого блока.

• Стирание занимает гораздо больше времени, чем просто запись на страницу.

Потому, что:

• SSD делают вид, что они являются стандартными жесткими дисками для хоста. Стандартные жесткие диски работают на секторах 512 байт (называемых LBA и пронумерованных от 0 до емкости диска, разделенной на 512), а не на 2048 или любого другого размера;

• и прошивка SSD должна делать много подделок в фоновом режиме, так как на самом деле нет 512 байт для хранения данных, как на вращающемся жестком диске;

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

SSD поддерживают то, что называется таблицей LBA to PBA. Например, операционная система сообщает SSD о необходимости записи в LBA 20, но на самом деле она может выглядеть как "Flash chip 2 page 56". Это поддерживается в таблице LBA to PBA.

Прошивка SSD попытается направить запись на новые страницы и избежать стирания, если это необходимо. Если нет доступных неписаных страниц, придется перетасовать вещи и сделать чтение / возможно написать где-нибудь еще / eraseblock / написать кучу вещей в обратном цикле.

Таким образом, таблица LBA to PBA может быть абсолютно случайной.

TRIM сообщает твердотельному накопителю, что он может удалить записи из этой таблицы (или пометить как "LBA еще не записано") и фактически стереть некоторую флэш-память и сделать ее доступной для быстрой записи в будущем.

Вот почему запись всех 0x00 или 0xFF не эквивалентна. Только TRIM сообщает прошивке, что все в порядке, чтобы не отслеживать вещи в этой таблице и считать флэш-память неиспользованной - и стереть ее при подготовке к новым операциям записи.

Запись всех результатов 0x00 или 0xFF в полную таблицу LBA-to-PBA, которая отслеживает данные, которые, по ее мнению, вы используете, и вещи будут оставаться медленными из-за необходимости перемешивать их и читать / стирать / перезаписывать.