NY152:
если он это будет делать именно в момент записи, скорость этого процесса вашего ссд вряд ли вас обрадует. Потому что , просто из вики
Слушайте, интересный вы человек, вам тут все разжевали, но нет, вы все равно даете ссылки на то, чего не понимаете
Вы же сами пишите, что блок стирается и записывается целиком и тут же говорите, что его можно стереть заранее Как же это у вас все уживается вместе? При поступлении команды на изменение блока происходит следующее:
1. Проверяется пустой блоки или нет. Ну тут сложнее несколько, на самом деле SSD знает все свои полностью пустые блоки и пишет сперва в них, если такие еще остались.
2. Если пустой в него сразу же пишется информация
3. Если нет, то читается старая в кэш и дописывается новая в кэше же
4. Блок стирается
5. Блок записывается целиком
Где тут противоречие с тем, что я писал ранее?
На счет команды trim.
Она делает, вернее может делать, 2 вещи
1. Находит все блоки в которых, по записям SSD в таблице трансляции, более нету никакой полезной информации и очищает их, это то о чем вы пишите
2. Оптимизирует свою таблицу трансляции или, если диск очищается полностью, очищает ее.
Эти действия вообще никак не связаны с "дефрагментацией", в кавычках потому, что, как и писал ранее, для SSD этот термин не применим, там нету такой фрагментации как в HDD этот термин - глупость для SSD.
NY152:
что естественным образом сильно тормозит накопитель
Примерно как еще одна запись блока, по времени. Поэтому и рекомендуют иметь свободное место на диске, чтобы писать сразу в чистые блоки.
NY152:
если остановить здесь запись на 60% , и через пятнадцать минут начать писать по новой, с какой скоростью возобновится запись, 45мб или 450? и почему?
Со скоростью 450. Но это не имеет ничего общего ни с "дефрагментацией" ни с очисткой ячеек.
Просто срабатывает SLC кэш - область ячеек, которая работает в другом режиме чем все остальные, в более скоростном режиме, когда объем ячеек меньше максимума, они работают в обычном, двоичном режиме, что сильно быстрее чем работать в режиме когда храниться 3 или 4 бита данных в одной ячейке. Во время простоя, или когда кэш заполнен, SSD в фоне переносит данные из кэша в область где уже большая плотность записи на ячейку, это заметно медленнее, что вы и видите на графике. Кэш освобождается - скорость восстанавливается. Но это никак не связано вообще с объединением данных или чем-то еще. Это просто перенос данных из быстрой, но маленькой по объему памяти, в более медленную, но значительно большую по объему. При переносе данных SSD руководствуется, в общем, алгоритмы достаточно разные могут быть в деталях, теми же правилами, что и при обычной записи, а именно, по возможность, старается писать данные в разные ячейки, не важно один это файл или разные, просто для того, чтобы увеличить ресурс.
Если вы будете писать в один и тот же файл в одно и тоже место даже постоянно, то данные не будут писаться в один и тот блок, а будут писаться в разные блоки все время, для балансировки ресурса ячеек ну и, по возможности, в те, которые полностью пустые, для скорости.
Так же при переносе данных из SLC кэша, так как данных много, пишет их сразу же блоками, чтобы заполнять блок целиком и опять же сократить количество перезаписей блоков. При этом он вообще ничего не знает о файловой системе, то есть не может делать никакой "дефрагментации" просто потому, что он не знает где там какие файлы, данные и прочее. Он оперирует блоками и при модификации даже части блока предпочтет просто записать все данные, старые и новые, в новый блок, а старый очистить, сделав его готовы для записи сразу.
Надеюсь теперь все встало на свои места?
