Цитата(alcosar @ Aug 9 2006, 20:46)

Цитата(Harbour @ Aug 9 2006, 08:43)

дык, а как к примеру Вы будете делать readdir("/") на такой системе - всю флешку просканируете ?
Да. По времени это довольно быстро. Тем более, что начинать файл можно со страницы кратной 4 - в 4 раза быстрее.
Справедливо только для маленьких флешек - для флешей >=64Mbit это десятки тысяч секторов, что выливается в _минуты_ поиска. В любом случае алгоритм не масштабируемый, т.е. время поиска линейно зависит от обьема носителя, что не есть good. Далее, если сделать начало файла с определенной границы, то сектора на этих границах будут иметь бОльший wear level чем данные, т.е. они быстрее накроются. А время, которое уйдет на постройку дерева версий - для такой embedded системы при рестарте уже смело можно выводить на LCD что-то типа - "откинтесь на спинку кресла"

В инете полно алгоритмов, скорость сканирования dir_entries для которых, не зависит от обьема флешек.
Цитата
Затем, нужно дописать в файл - ведется типичный лог событий embedded устройства - при Вашем варианте если файл "зажат" между другими ничего не выйдет - придется или все содержимое копировать в конец и потом дописывать или строить дерево версий. А если нужно будет переписать что-то в середине файла [по правде не сильно нужная опция для embedded применений, но все же] ?
Цитата
Продолжать лог как новый файл.
Оно то понятно, что продолжать, а накладные расходы по памяти для дерева при этом какие ? У меня получилось (n_sect/8) + superblock + sector_buf, что для 16Mbit флеша (у меня at45db16) дает (4096/8 + 512 + 512) = 1k5 ram'ы, при монтировании [алгоритм O(1)] в самом худшем случае (пустой флеш) нужно прочитать 192 сектора, в лучшем (заполненный) - 3.
Сообщение отредактировал Harbour - Aug 10 2006, 01:58