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

973
ivan_pozdeev

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

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

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

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

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

1 Логический сектор, то есть то, что видит хост.

1
SSD быстро изнашиваются, если вы пишете в каждый сектор. Каждая ячейка имеет ограниченное число раз, когда она может быть записана, и после этого ячейка слишком медленная, чтобы быть полезной. Если у вас есть причины безопасности для «безопасного стирания» диска, то знайте, что большинство твердотельных накопителей перегружены, так что есть запасные физические ячейки. Таким образом, тот, кто может использовать служебную программу поставщика для доступа к каждой отдельной ячейке, может иметь доступ к данным, которые, по вашему мнению, были «надежно удалены». Christopher Hostage 6 лет назад 0
Похоже, вы спрашиваете, будет ли какой-либо контроллер выполнять сборку мусора, проверяя, содержит ли * логический * блок (чтобы быть менее неоднозначным, * читает *) все ноль? (Например, авто-TRIM, если это так?) Tom Yan 6 лет назад 0
@TomYan Это даже проще. Это нужно проверять только по входящей команде записи. Если операндом данных являются все нули, запись не выполняется, и логический блок вместо этого отображается. ivan_pozdeev 6 лет назад 0
Я слышал о контроллерах, которые были бы * умными * достаточно, чтобы игнорировать заполнение нулями после того, как оно превышает определенную непрерывную длину. Я бы предположил (часть), что логические блоки будут в состоянии, эквивалентном TRIM. Tom Yan 6 лет назад 1
@ Tomyan Я читал, что твердотельные твердотельные накопители (например, Samsung PRO / EVO) сжимают данные на лету, чтобы достичь еще более высоких скоростей чтения / записи - естественно, часть нулей сжимается очень хорошо. ivan_pozdeev 6 лет назад 0
«Таким образом, если нет доказательств того, что это действительно серьезные проблемы, ответы, авторитетно утверждающие, что они (а не только предполагающие это), неприемлемы». - Они приемлемы с точки зрения сообщества. Они могут просто не ответить на ваш вопрос. Я предостерегаю вас от использования словоблудия как «неприемлемо», поскольку в качестве автора вопроса вы хотите, чтобы как можно больше людей хотели написать ответ, отрицательный словосочетание могло бы прогнать людей, которые могут знать ответ на ваш вопрос. Ramhound 6 лет назад 0
Я VTC слишком широк, потому что слишком много типов флэш-контроллеров. Вы должны серьезно сузить сферу этого вопроса. В любом случае, Super User не является исследовательской службой. Daniel B 6 лет назад 0
@DanielB Есть не так много отличительных методов, которые используют SSD, и они обычно упоминаются в технических документах / обзорах / и т.д. то есть не требуют знания прошивки на уровне конкретных моделей. Контроллеры различаются только в деталях их реализации, которые здесь не имеют значения. ivan_pozdeev 6 лет назад 0

3 ответа на вопрос

1
sawdust

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

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

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

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

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

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

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

ДОПОЛНЕНИЕ

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

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

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

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

`Стертый сектор заполнен байтами 0xFF (все) .`? Тогда откуда взялись `RZAT` в ATA и` LBPRZ` в SCSI? (где Z ноль) Tom Yan 6 лет назад 0
@TomYan Нули, которые возвращают эти команды, не являются результатом чтения мультимедиа. Они генерируются логикой на диске, когда вы читаете "TRIM" d блоков. Jamie Hanrahan 6 лет назад 0
@TomYan - В документации по флеш-чипам четко указано, что стертое состояние - это все. Документация по SSD четко указывает, что контроллер будет * отвечать * нулями за данные, когда этот флаг установлен для «свободного» (т.е. не отображенного) LBA / сектора. Это не означает, что LBA / сектор на самом деле содержит нули, так как это на самом деле снизит производительность (то есть он не удален и не готов к записи). См. Последний абзац раздела 3.8.2 http://www.seagate.com/www-content/product-content/ssd-fam/1200-ssd/en-us/docs/100708406b.pdf. sawdust 6 лет назад 2
@sawdust см. мой комментарий в ответе Дэвида Шварца. Tom Yan 6 лет назад 0
_> и, видимо, ваш вопрос основан на этой ошибочной предпосылке ._ Вы не можете быть отцом от истины. Мой вопрос ни в коей мере не зависит от того, какой именно образец нужно написать. Кроме того, под «кажется, что он заполнен нулями», я имею в виду, что нули - это то, что возвращается хосту - я уверен, что в таких случаях вообще не выполняется чтение NAND (не метаданных). ivan_pozdeev 6 лет назад 0
@sawdust Кроме того, когда речь идет о логическом блоке, если он читает ноль, то он «содержит» ноль. Вот почему он был назван «логическим» блоком. Tom Yan 6 лет назад 0
@sawdust Наконец, я предположил, что такие «записи» могут обрабатываться особым образом, без фактического стирания / перезаписи любых (не метаданных) блоков. Похоже, вы вообще не читали мой пост, прежде чем ответить. ivan_pozdeev 6 лет назад 0
_Когда бы программа ни записала сектор со всеми нулями ... ваша схема позволила бы SSD ... обрабатывать его как не отображенный сектор, а не используемый сектор и назначенный файлу. Когда-либо слышал о [разреженных файлах] ( https://en.wikipedia.org/wiki/Sparse_file)? Пока хост читает из определенного логического сектора именно то, что записал ранее, ему все равно, как диск обрабатывает его внутренне. Это не похоже на то, что несопоставленный _logical_ сектор SSD может внезапно начать содержать что-то другое, что обнуляет, не так ли? ivan_pozdeev 6 лет назад 0
@ivan_pozdeev * «Пока хост читает из определенного логического сектора именно то, что записал ранее, ему все равно, как диск обрабатывает его внутренне» * - Неверно. Я работал над системами, которые написали заполненные нулями файлы, чтобы гарантировать, что сектора доступны и распределены, то есть чтобы гарантировать, что (пере) запись этого файла не вызовет ошибку «нехватка места». Обратите внимание, что «разреженные» файлы должны быть реализованы только на уровне файловой системы (которая может определять, что такое «не данные»), а не на уровне устройства хранения. sawdust 6 лет назад 1
@sawdust Хороший вопрос о "из космоса". Но это не относится к твердотельным накопителям, потому что они гарантируют, что они способны хранить всю объявленную емкость данных одновременно. Я никогда не предлагал использовать все свойства разреженных файлов, например, свойство, которое может быть больше доступного хранилища. Только то свойство, что куски, которые являются всеми нулями, на самом деле не нужно хранить. ivan_pozdeev 6 лет назад 0
1
David Schwartz

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

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

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

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

@RickBrant Моя точка зрения такова, являются ли физические секторы за сценой "заполненными одним" - это не входит в сферу действия ОП (и я не думаю, что "один" - хороший способ выразить это, когда вы говорите об электронном уровне). ОП должен знать, что нулевые логические блоки не обязательно означают, что любой физический сектор освобожден. В противном случае он, естественно, приходит с вопросом типа «могу ли я подражать TRIM одним заполнением». Речь шла не о том, как заполнен сектор, а просто о его состоянии в смысле «обеспечения логическим блоком». Tom Yan 6 лет назад 1
@ TomYan Я не согласен с тобой. Он не вернулся бы с таким вопросом, потому что он знает, что чтение в обрезанном секторе возвращает все нули. Что касается того, что он выходит за рамки OP, понимание различий между физическим и логическим секторами имеет решающее значение для понимания того, что такое TRIM и что делает, и почему написание не заменяет его. David Schwartz 6 лет назад 0
@DavidSchwartz Я знаю, как работает TRIM. И именно поэтому, выведен технически возможный способ эмулировать его: такие записи могут обрабатываться особым образом, который делает именно то, что сделал бы TRIM. ivan_pozdeev 6 лет назад 0
Обрезанные секторы могут не обязательно возвращать ноль, не на всех дисках, поэтому существует «бит» RZAT / LBPRZ. Это полностью зависит от реализации TRIM на дисках. Конечно, хорошо знать, что такое электронное состояние «сброса» «физического сектора SSD», но назвать его заполненным и сравнить его с состояниями на уровне логических блоков? Я не вижу, насколько это уместно или правильно. Tom Yan 6 лет назад 0
@TomYan - * «Я тоже не думаю, что« один »- это хороший способ выразить это, когда вы говорите об электронном уровне» * - Стираемая необработанная флэш-память будет читаться как все. sawdust 6 лет назад 0
«Я знаю, как работает TRIM». - Так почему вы пришли к выводу, что если заполнить диск нулями вместо 1, вы получите то, что хотите? Ramhound 6 лет назад 0
@Ramhound, потому что _Прежде чем когда-либо записывался сектор SSD *, похоже, что все заполнено нулями. (* Логический сектор, то есть то, что видит хост.) _ ivan_pozdeev 6 лет назад 0
@ Опилки Я никогда не говорил, что нет. Предложение, которое вы цитировали, никогда не касалось этого факта. Речь шла о том, чтобы называть его «один (заполненный)» вводящим в заблуждение, как будто речь идет о записи единиц в / через логические сектора. Вот почему я предпочитаю «сбросить», или каков бы ни был «заряд» (положительный / отрицательный). Что еще более важно, «один заполненный факт» здесь не имеет значения, потому что он также будет «один заполненный» (электронный / физический смысл), если вы «один заполненный» (логический смысл, то есть нормальная запись блока), но это не значит, что он "не нанесен на карту" / "не используется" / "trim'd". Tom Yan 6 лет назад 0
1
LawrenceC

Могу ли я подражать 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, которая отслеживает данные, которые, по ее мнению, вы используете, и вещи будут оставаться медленными из-за необходимости перемешивать их и читать / стирать / перезаписывать.

Еще одна не проблема. Поскольку описанная «специальная запись» влияет только на «таблицу LBA в PBA», не имеет значения, что блоки страниц / стирания больше, чем логические сектора - на самом деле ничего не будет записано в NAND. Единственная проблема - блок должен быть помечен как «частично свободный», но TRIM также принимает набор диапазонов логических блоков (см. Https://stackoverflow.com/questions/3267244/ata-trim-specification/3267568#3267568. для ссылки на спецификацию), поэтому привод должен быть в состоянии справиться с такой ситуацией в любом случае. ivan_pozdeev 6 лет назад 0
Я бы не стал отказываться от каких-то дрянных прошивок, чтобы фактически записать 0 во флэш-память. У вас нет возможности узнать, что делает прошивка, если у вас нет исходного кода, вы скомпилировали его и самостоятельно установили его на устройстве - или производитель прошивки специально гарантирует конкретное поведение. Вы можете различить истинное поведение, измеряя время выполнения команд. LawrenceC 5 лет назад 0

Похожие вопросы