> контроллеру не нужно. Запись ФС будет происходить без задержек кроме той,
> что нужна на полную очистку блока (принимаем, что размер блока ФС

О боже. В этом и проблема. Очистка блока по меркам 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% от объёма флеша.