casm82
Junior Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Ради эксперимента попробовал скопировать первые 282 папки из кэша размером 42,4 МБ (44 489 819 байт).
Копировал в Far 1.70 2087 с помощью плагина FileCopyEx 1.7 в nul устройство (\\.\nul\), с включенным параллельным копированием.
Создал три вирт. диска (все с кластером 512 байт) – NTFS (со сжатием), NTFS (без сжатия), FAT32 - на каждый скопировал выбранные папки.
Для каждого диска делал три серии копирования. После каждого копирования Far закрывал и выполнял высвобождение памяти с помощью RAM Optimizer (из Customizer XP). Системный кэш при этом уменьшался до 18-20 МБ, вместо 180-250 МБ при обычной работе.
Были получены следующие данные:
| Время\ ФС | NTFS без сжатия | NTFS со сжатием | FAT32 | | 1 замер | 15,4 | 15,6 | 47,4 | | 2 замер | 20,2 | 17,5 | 54,2 | | 3 замер | 21,4 | 20,4 | 58 | | среднее | 19,00 | 17,83 | 53,20 |
Как оказалось, для моего случая, на малых файлах ntfs со сжатием выигрывает.
Однако думаю, что индекса все же лучше использовать файлы, чем потоки ntfs.
Во-первых, пользователи других ФС смогут использовать индекс, переносимость кэшей и все что выше было написано выше. Во-вторых, можно получить доступ к данным для просмотра/редактирования – мне все-таки спокойней, когда я имею доступ ко всем данным.
Цитата:
Цитата:| Давным-давно была идея некого "индекса". Продумывались варианты один файл на кеш, хост, папку. Остановились на одном файле на хост (папку лежащую в корне кеша). Осталось только написать формат файла и функции работы с ним (всего-то). |
Проблем особых тут не вижу, только надо придумать как быть при сливании двух кэшей. |
А что если в корне каждой папке генерировать файл с именем вида db_xxx….x.hci, где
xxx….x – уникальное число.
Число можно задать вида YYYYMMDDhhmmss
где YYYY, MM, DD, hh, mm, ss – год, месяц, день… создания индекса
Или просто случайное число, 6-ти или 7-ми значное (у меня, например, Diskeeper показывает что на диске 87 тыс.файлов).
Возможна комбинация формат времени и случайного числа.
При сливании кэшей, получиться несколько файлов в одной папке.
Далее либо вручную указать HC пересобрать индекс (отбросить дубли в файлах и склеить индексы), либо в фоне - перед обращением к папке.
Можно помещать файлы индексов и тот же RAM-кэш, для ускорения работы (на подобии soft updates).
При создании индекса с помощью файлов, так же потребуется учесть способ их обновления. Если считать индексы как дополнение к ФС, то возможно, выбрать варианты ( см. ) - индексы обновлять синхронно, асинхронно, с использованием журналирования, или с использованием «soft updates».
По-моему, введение индексов довольно сложная задача, поэтому думаю, может все же сначала реализовать плагины, а после уже добавить в виде плагина поддержку индексов. Всё же когда на этой идей будут работать несколько человек, результат будет достигнут быстрее.
Так же в случае поддержки плагинов, возможно будет написать два плагина – один для хранения индексов в потоках ntfs, второй – для хранения в файлах. И уж пусть каждый сам решает какой плагин ставить.
|
Всего записей: 128 | Зарегистр. 04-06-2006 | Отправлено: 22:47 01-10-2006 | Исправлено: casm82, 22:48 01-10-2006 |
|
После такого отсева, походу останется 1 (максимум 1.5) юзера (ну а куда попрёшь против статистики, представленной forever'ом) 
Вот только насчёт последнего пункта скромное уточнение: технология iStreams затыкается снятием одной гульки... 
) одного и другого модуля могут быть разными людьми 
Т.е. ты согласен в Историке делать два способа реализации: с использованием потоков и без? Сделать один универсальный способ не по джидайским правилам? 
Чтобы не было еще "повторов": мне нечего тебе писать в приват (а что в твоем представлении я тебе должен писать?). 
Какуюнить аргументацию в их пользу, а не демагогию. Почему-то ведь ты грудью встал на защиту потоков - еще б потрудился объяснить почему. 
