>FAT32 на флэше только из-за совместимости с операционной систмой Windows. ...и еще вагоном и маленькой тележкой всякого хлама.Одна из немногих ФС которая проста в реализации при всей дебильности.
>— "ротация" блоков и так неплохая и главное полностью равномерная,
Да-да, особенно в зоне таблиц FAT такая ротация блоков что NAND с его несколькими тыщ перезаписей честно сыграет в ящик в зоне FATов после записи пары тыщ файлов на флеху :).Если в флеш брелке эти перезаписи придутся за счет встроенного контроллера размазывающего записи на *разные* блоки NANDа и каждый блок отсилы 1-2 раза перезапишется, в просто nand чипе приделанном напрямую к процессору этим заняться некому кроме самого процессора разве что, чисто программно.Что у него сожрет вагон ресурсов.
>со стёртой инфой по своему усмотрению, чтобы не фрагментировать пространство.
... но для флеша прицепленного к CPU "в лоб" - без дополнительного навернутого контроллера 1 хрен не подходит, ни тот ни другой.
>Ну так в каждом современном ARM-процессоре интегрирован собственный контроллёр
>флэш-памяти. Поэтому надобность в отдельной микросхеме отпадает. :)
Некоторые бсдшники просто гении языком трындеть.А если б еще и мешки пробовали ворочать то знали бы что одно дело - навернутый чип контроллера флеша с своим собственным процессором и наворотами и другое - простенькая периферийка прицепленная к ARM ядру которая позволяет ему в лучшем случае читать\писать это относительно по человечески, в идеальном случае может еще ECC считает из довесочных блоков, как максимум.Никакой перестановки блоков такая периферия ессно не умеет - она просто позволяет ARMу иметь дело с чипом и не более того.Если нужна трансляция адресации блоков для размазки записей - флаг в руки ARM процессору упираться самолично.Потому что у его периферии в отличие от чипов контроллеров процессорное ядро и навернутая логика - сам ARM и есть.Никто не будет запихивать ему в помощники крутой контроллер занимающий целый кристалл чипа который чего доброго покрупнее чем весь этот ARM.
>флэш (порядка 10-15%, например, в Ext3FS), он ещё и изнашивает сам
>носитель!
Никто не юзает на гольном nand flash ext3, обломайтесь.А вот JFFS2 там разумно смотрится.Сперва почитайте как он реализован потом трындеть будете.Заодно поймете как тупо вы с вашими предложениями UFS смотритесь.
>В случае с UFS2 "мягкие обновления" не нуждаются в журнале на носителе
Для тупых еще раз: NAND флеш без крутого контроллера который займется размазыванием не годится для традиционных файловых систем.А это как раз тот случай который у нокии.И JFFS2 как раз ФС заточенная на прямой интерфейс к NANDу и использует специфику работы флеш-памяти.Вон та фс - тоже.А general-purpose поделки в именно таком варианте использования NAND - непригодны.Инжинеры Нокии в отличие от вас это понимают.
>Отсутствие сбоев возлагается на утилиту-ремонтника (fsck),
Знаете куда вас пошлют юзеры с девайсами которые будут делать fsck по 10 минут?Не нужны никому такие девайсы которые по 10 минут грузятся и тормозят чекая ФС и выжирая батарейку.А винмобайл 2003 конечно да, в 2008 году актуальнее некуда.Чтоб вы знали, в более новых системах MS от этого ушел.А вы если хотите юзайте решения 2003 года в 2008 году, вопрос в том - сумеете ли вы хоть 10 000 столь дефективных девайсов кому-то продать.
>требующую только небольших ресурсов процессора в случае неконсистентности ФС.
Понимаете в чем дело, если CPU вместо того чтобы спать 10 минут молотить будет - он неслабо посадит батарею.И кстати небольшие они когда у вас core quad.А когда это ARM на несколько сотен МГц и ему еще надо интерфейс нанда дергать и прочая - нагрузка там будет эдак 50-100% времени CPU.При этом стартап системы будет меееееедленный и печаааальный, а приложения запущенные сразу после старта системы будут лагать еще десяток минут пока оно там в фоне чекать будет.Короче в сад с вашими педальными решениями.Инжинеры Нокии не тупее вас, поверьте.
>Я привёл аргументы бесполезности журнала на флэш:
Вы сказали всего лишь много фигни, не имея представления о специфике задачи.
>он лишь гарантирует консистентность файловой системы, использемой для данных
Как вы понимаете, если юзер писал файл и тут вдруг акк сдернули или он резко просел (т.к. древний) - потеря данных неизбежна в любом случае, не успеет файл из RAM слиться в флеш.Один фиг останется недописанным.В случае JFFS2 кстати полной потери данных не произойдет, скорее всего после отката транзакции юзеру просто останется видна прошлая версия файла в том виде как было до начала этой записи.Нормальный откат вполне.И не надо тарахтеть 10 минут fsck...
>для самого журнала). Журнал изнашивает флэш не лучшим образом, чем записываемые
>файлы, но позволяет обходиться меньшим объёмом RAM.
...и все это ламерское трындение было еще и не про JFFS2, где журнал сделан так что логично и хорошо ложится на физическую организацию NAND flash, ибо для того и сделано.Если человек не представляет себе что такое Flash File System и чем она отличается от обычной - тут опаньки.Вы или читаете мануалы как работает нанд и понимаете почему там юзают такие ФС или несете чушь которая верна для ФС общего применения на дисковых накопителях и флеш-брелках.Но чушь, когда разговор идет о NAND прицепленном без всяких наворотов "в лоб" к процессору, который в итоге имеет дело с NAND в виде как он есть на самом деле.Ибо накристальная периферия обзываемая контроллером нанда в данном случае лишь контроллер физического интерфейса а логикой работы он не занимается и это уже флаг в руки ARMу упираться.
>ответ зависит от того, как часто производится запись и модификация данных.
Во флеше она производится весьма специфично.И JFFS2 учитывает это.RTFM короче - и про JFFS2 и про то как работает NAND флешатина и вообще флеш память.
>Nokia зарабатывает деньги на своих проприетарных технических идеях
А сегодня эту "проприетарную" идею внедрили в линуксное ядро.В том числе и потому что Нокии это надо.Они используют линукс в своих железках и в данном случае им жаться не логично.Им на халяву протестят ФС а если надо то и пофиксят.За месяцы.Если бы они делали это сами - у них бы ушли годы.Хороший пример того как обратная отдача позволяет быть в выигрыше всем участника процесса.ALL-у хорошая ФС нужная в ряде задач, а взамен орава програмеров и юзеров посмотрит в код, потестят, попробуют на зуб а если надо то и поправят чего надо.И потом та же нокия сможет просто брать ядро и юзать его, а не пыжиться поддерживать свое проприетарное добро в одну харю что не слишком то эффективно.
>UFS2 сканируется в фоне.
UFS2 сделан без учета физических особенностей NAND, на этом можно и закончить.Ибо этого достаточно чтобы ни один псих не стал юзать такую файловую систему на гольном NAND чипе не прикрытом контроллером.Это не наезд на UFS2, благо, FAT, EXT2 или что там еще для складывания на NAND чип в виде как он есть точно так же непригодны.Нокия в отличие от вас просто делает свою работу.Хорошо и без фанатизма, юзая подходящие решения на подходящих задачах.И ваши сопливые и ламерские советы их инжинерам не требуются - эти инжинеры свое ремесло знают.Лучше вас, кстати, судя по вашему постингу.
>И ещё фрагментация файлов не больше 5% — это один из лучших
>показателей среди популярных ФС.
На флеше кстати фрагментация вообще до балды: у него seek time в районе нуля и фрагментация ни на что не влияет.Скорость чтения файла с 100 фрагментами мало отличается от линейного чтения.Это харду пока он головы подвинет проблемка, а у флеша механики нет.Он в плане *чтения* примерно как оперативка - память с произвольным доступом.С записью все сложнее.Там уже и про блоки вспоминаем и про физическую структуру чипа.
>Да пожалуйста.
They did it! :)
