> быть непосредственно записаны лишь в том случае, когда они чисты. Ну, ты молодец - пересказал 294-му как работает флеш память. Правда вот я уже примерно 12 лет как в курсе что такое флеш память и как ее программировать. Сущий пустяк :).
> Так как очистка ячеек в странице необходима перед тем, как в
> них можно будет записывать снова, но только целый блок может быть
> очищен, процесс перезаписи инициирует цикл чтение-очистка-модификация-запись:
Спасибо, вику пересказываешь хорошо. Правда вот учитывая что я плотно копался в такой механике самолично и даже разок напрограммил простейший вариант этой логики сам - ну как бы удачи в рассказах.
А вот что мне интересно - так это с чего ты взял, что число циклов флеша при "превентивном" GC с подыгрышом TRIM будет больше чем при протирании "когда приперло и иначе никак". Поскольку в уже прописанную область записать без стирания все-равно не получится, цикл стирания там будет нужен по любому, чтобы туда что-то записать. А вот когда у GC wear leveler есть свобода маневра - он это в целом может делать несколько реже. Потому что может оптимальнее раскладывать запрос на имеющиеся чистые блоки. А если все блоки всегда "занятые" (без trim о их [не]занятости накопитель ничего не знает) - накопитель может ориентироваться только на сведения о том что надо переписать их текущих запросов. И оперировать лишь маневровым запасом блоков. Если просто представить себе как это будет работать - станет понятно что при этом оптимально раскинуть в блоки получится уже не любой запрос. Ведь стирать можно только то что в рамках текущих запросов на запись. Остальное надо сохранить - "а вдруг это пользовательские данные?". Поэтому read-modify-write будет больше и он будет кантовать бОльший объем данных и менее оптимально чем мог бы. Так что в среднем wearing пожалуй даже сократится.
