> контроллеру не нужно. Запись ФС будет происходить без задержек кроме той,
> что нужна на полную очистку блока (принимаем, что размер блока ФС О боже. В этом и проблема. Очистка блока по меркам CPU/шины - операция длиною в вечность. Ее лучше делать в фоне, не заставляя шину ждать. А писать в свободные блоки левелера.
Я тебе секрет открою, так и быть - современный контроллер всё равно не будет стирать целевой блок, запишет в свободный блок "резерва". Поэтому даже потерю производительности заметишь не всегда. Но вот блоков этих мало, и веаринг драйва в итоге будет неоптимальным. Совсем-совсем.
> Контроллер SSD записывает данные на флэш только поблочно
Бред. Поблочно производится только очистка. Запись может идти постранично.
> Контроллер SSD по команде ФС записывает данные на флэш только поблочно
Чушь. См. выше.
> величина — блок SSD, имеющий размер 512 килобайт.
На практике - от 64Кб до 2Мб в зависимости от организации флеша. Встречаются варианты и с <64Кб, но сомневаюсь, что идут в "бытовую" продажу в виде SSD. В основном это встроенные флеши на разных мобилках и прочем.
> Модификация данных происходит в оперативном кэше SSD с целым блоком. Если есть
Еще раз: никакой модификации данных не происходит. Данные пишутся в один из "резервных" блоков постранично, на чистые страницы. Если чистой страницы на данный момент нет - запускается GC левелера, превращая всю операцию в томительное ожидание.
> Но они тоже будут перезаписаны (освежены), так как контроллер SSD записывает
Это происходит только в моменты работы GC.
> Да ну. Оптимальное распределение блоков ФС по всему пространству носителя вроде как
> не тайна за семью печатями.
Это делает сам контроллер. Все попытки навязать ему сверху какое-либо распределение приведут только к быстрому занятию всех активных блоков рабочего набора. А без TRIM - еще и к тому, что контроллер будет вынужден всегда веарить за счёт резерва.
> для модификации его блоков. В случае с совпадением размеров блоков операция
> очистки производится для всего блока SSD сразу, данные записываются большими порциями
> — нет оверхеда на подчистку отдельных страниц.
Только в случае, если есть полностью свободный блок. А учитывая, что TRIM у нас нет, и пишем, как попало - скорее всего полностью свободных блоков не будет, и на каждую запись будем получать ERASE. Малый размер блока даже несколько более выгоден в случае SSD, поскольку позволяет не делать ERASE на запись 1 байта, если в наличии есть свободная страница. В идеале блок должен быть именно размером со страницу, чтобы не выполнять копирования, и не стирать целые блоки при записи мелких файлов.
> Ты действительно веришь, что GC после своей работы с блоком разделяет блок
> на отдельные страницы (очищенные и занятые), компонует очищенные в чистые блоки
> SSD и складирует их куда-то?
Именно так он и работает. Читай публикации по веарлевелингу флешей. Работа GC чем-то сходна с классическими дефрагментаторами. Для перекомпоновки, к слову, достаточно всего лишь одного резервного блока. Но левелинг при этом будет никакой, естественно, поэтому на "резерв" реально берется обычно 5-10% от объёма флеша.
