>FusionIO - это разновидность SSD, только с другим (относительно того, к которому
>привыкло большинство) интерфейсом. Кстати говоря - представлять flash-диски как якобы-HDD, с якобы-секторами в 512 байтов, с сокрытием реальной физики флеша и прочая - очень идиотская идея на самом деле, т.к. чертовски усложняет оптимизацию по скорости.Благо, *реальная* физика флеша здорово отличается и ничего общего с 512 байтными секторами не имеет.Запись именно блока в 512 байтов - это в случае NAND гарантированный влет на тормознутый read-modify-write силами его встроенного контроллера, который в ответ на такой запрос внутри себя вот такую вот последовательность действий отпедалит. Соврав всем что это запись 1 512 байтового сектора, просто такая вот медленная.На самом деле это как минимум чтение 2 или сколько там Кб страницы, патч 512 байтов, в лучшем случае - запись.В хучшем это вообще erase целого eraseблока+только потом запись(страницы можно писать только последовательно и фиг его там знает, выполнится ли это условие или нет).Чего доброго запись будет даже более чем 1 страницы даже (если на стертом erase-блоке было не пусто+в зависимости от логики FTL).И все это будет отпедалено ради якобы-атомарной записи 512 байтов!Пи$#ец...
ЗЫ: кстати браво форматируя штукенции с флешом не стоит забывать что всего лишь небольшая лажа в формате aka выбор размещения структур наобум и ... можно просрать скорость В РАЗЫ.Если скажем блоки ФС придутся на границу страниц флеша так что на чтение\запись 1 блока ФС будет вместо 1 страницы читаться\писаться 2 - выйдет жутко неоптимально и скорость весьма хардкорно просядет.Кстати если обратить внимание - дефолтовая ФС на продаваемых картах памяти, флехах и прочая как правило очень своеобразно скроена.Она там неявно и втихаря подогнана под физику флешатины, так что блоки ФС (у фат - кластеры) не попадют на середину границы страниц.А служебные структуры (mbr, таблицы FAT) сделаны так что во первых, MBR живет в отдельном erase block (и поэтому никогда не попадает под read-modify-write логику и потому не может слететь при проблемах), во вторых FAT'ы выравнены на erase-block, и так далее.
Ни один "обычный" форматтер ни в 1 ос этим не заморачивается и потому при попытке переформатить флеш-диск (как минимум для usb-флех верно) или MMC\SD карту - можно получить очень говняный результат. Кому интересно - подробный гайд по ускоренному убиению и деградации флешек - воон там: http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device
P.S. а кто чувствует себя реально крутым и понимает как устроена та или иная ФС и как работает флеш - u're welcome: предлагается подумать над интересным вопросом: как оптимально разложить на флеш что-то более вменяемое чем дефективный и морально устаревший FAT32.Для FAT32 на вон той паге есть пример того как мануфактуреры флешек его раскидывают с оптимизацей под флеш.Ну как, а нам слабо что-то помощнее оптимально раскинуть?Я уже мозг над этим изрядно поломал.А вы?Да, производитель кстати может читерствовать: ему известна логическая организация чипаков флеша и логика работы FTL-уровня в контроллере.Нам остается только *гадать* на эту тему.Хотя на самом деле - можно произвести серию бенчмарков и на их основании прикинуть реальную структуру по их итогам (если записи хреново накладываются на структуру флеша - будет тормозно, если хорошо - будет быстро).
P.P.S. Кстати пользуясь случаем передаю привет цыркачу iZEN по части "оптимизации под флеш память".Теперь доходит что такое *настоящая* оптимизация файловой системы под флеш? :D. Грамотно положив лэйаут ФС на страницы и erase блоки можно достичь оптимальности в плане отсутствия лишней работы для контроллера флехи и минимума перезаписей из возможного.Вот за контроллер и сокрытие им структуры флеша хочется их всех слегка убить.Заметили насколько усложняется оптимизация из-за поддержки совместимости с механическими хардами на уровне логической организации?Суки.Надо ж так прогресс тормозить ради совместимости.
Regards, your Captain Obvious :D
