Только на хороших.На всяких там usb и прочая - такого нету.И кроме того - и на много его хватит при рандомных доступах по всей поверхности?У флеша seek time мелкий а потому в случае крутого диска есть соблазн наподдать ему параллельных запросов в разные участки, с этим как раз у механики проблемы.А вот тут то и будет опа.ФС считают что писать кусочками по 512 байтов в рандомные точки - вполне валидно в принципе.А то что это очень не здорово для носителя они могут и не знать.И не знают.Ну а уж о том чтобы выровнять структуры ФС на erase-block'и сэкономив флешу циклы перезаписи (и время на них) и подавно в обычном случае никто не думал.У жестких дисков то ничего такого нет.А большинство ФС делались именно под них.А контроллер скрывая детали физики флеша еще и делает такое выравнивание весьма негарантированной и нетривиальной операцией - кто ж документирует физическое устройство диска и как себя контроллер ведет там внутри?

>и контроллеры как правило оптимизированы, под то что бы не перезаписывать, пока
>есть возможность сделать переалокацию )))

Опять же - только хорошие контроллеры.Их таких не так уж много.И стоят диски от приличных производителей с таким контроллером - как задняя часть самолета.Зато всякого фуфла с примитивными контроллерами - навалом.Кроме того - опять же а как преаллокация переживает слет питания?Она логику журналирования не рушит?Журнал предполагает что если сказали нечто записать - это записано.А не то что железка где-то внутри себя будет ждать - а не допишут ли еще чего туда же.И, собственно, ФС в своем праве уповать на 512-байтные блоки.Или на что там еще.Не выровненое на страницы и erase-блоки, что было бы наиболее оптимально для флеша.

(Ps. виноват.не дописал)

))) смишной)

работают через интерфейс.
но обращаются к контроллеру, хоть флэш, хоть хард - головками управлять не пытаются)))
а вот куда будет произведена запись и когда и что поместить в кэш харда/ссд - решает его контроллер.

Нет, конечно.Вот только проблема в том что они работают с этим флешом как с обычным носителем.Как будто бы у него 512-байтные сектора которые можно индивидуально адресовать и записывать.А по факту - никаких секторов в 512 байтов там нет.Изображаются варварской эмуляцией путем read-modify-write страницы (которая у нанда обычно 2 или 4 Кб например).При этом операция получается не только не атомарной - она еще и соседние сектора затрагивает.Потому что у нанда атомарные операции - только со страницами, никак не менее.А это более чем 512 байтов.На что софт не рассчитывает в общем случае.Могу себе представить ситуацию когда питалово слетит так что это будет в процессе read-modify-write и похерится не только записываемый сектор (на что софт вполне может рассчитывать) но и несколько соседних (на что софт ессно не рассчитывает, т.к. у обычных жестких дисков запись сектора в принципе атомарная операция и соседние сектора обычно никак не затрагивает). Получается и более тормозно чем могло быть и стремно.А обычные файловые системы раскидывают по дефолту структуры как угодно, только не так как это было бы удобно реальному физическому носителю.