» HandyCache ( Часть 4 )

popkov
Цитата:

для тех, кто хочет, чтобы служба Автоматическое обновление загружала обновления через HandyCache написал .reg-файлик

Теперь обновления идут через HC, но в кэше сохраняется не все
Т.к. HC не поддерживает докачку.

mai62
Может сохранять кусочки файлов в кэше а потом склеивать их вместе?

C0USIN

Цитата:

Может сохранять кусочки файлов в кэше а потом склеивать их вместе?

Сохранять не сложно, только склеивать их потом вручную? Как автомат узнает какой кусок куда лепить, нет ли среди кусков дублей достаточно ли вообще кусков для полного файла?

Сталкивался кто нибудь с такой проблемой: у меня кэш на одтельном разделе диска (NTFS), ибо сильно фрагментируется и достиг 1Гб (более 200тыс. файлов). Соответственно разбухла до неприличия файловая система, подозреваю что MFT размазалась по нескольким разделам, а ведь это нехорошо сказывается на производительности всей ОС. Может преобразовать папку кеша в виртуальный диск? Какую программу для этого использовать? А может кто предложит другой путь.

А можно ее к usergate 4.0 прикрутить? Мне не нравится кеширование у UG.

mai62
Цитата:

Как автомат узнает какой кусок куда лепить

В конец имени файла дописывать информацию из заголовка
Range: bytes=305806-312466
Кусчки будут тогда называться примерно так file.cab#bytes=305806-312466

C0USIN

Цитата:

В конец имени файла дописывать информацию из заголовка

Уж лучше тогда нормальную докачку сделать чем за кем-то огрызки подбирать Тогда во многих случаях и качалка не понадобится.

spec321
Дефрагментировать диск пробовал? Только не встроенным дефрагом а чем-нибудь помощнее (Perfect Disk, например)

Цитата:

подозреваю что MFT размазалась по нескольким разделам

Такого не может быть. MFT будет на том же разделе. Просто она разрастается и тоже фрагментируется. Тут поможет оффлайн-дефрагментация.

Цитата:

Может преобразовать папку кеша в виртуальный диск?

Те-же яйца. Вид сбоку. Только скорость ухудшится.

mai62
Цитата:

Уж лучше тогда нормальную докачку сделать

А я разве не про это говорю? Что ты понимаешь под докачкой?


Цитата:

во многих случаях и качалка не понадобится.

Я направляю качалку напрямую всегда. Но что мне делать в Windows Update? Он запрашивает файлы кусочками по 6-8 килобайт. Хотелось бы сохранять все в кэше.

C0USIN

Цитата:

Что ты понимаешь под докачкой?

При обрыве закачки НС мог бы поытаться докачать файл, клиент этого и не заметит.

Цитата:

Но что мне делать в Windows Update? Он запрашивает файлы кусочками по 6-8 килобайт. Хотелось бы сохранять все в кэше.

Что сам останавливает закачку, а потом возобновляет? Сколько же там кусочков будет, тысячи?

mai62
Цитата:

Что сам останавливает закачку, а потом возобновляет?

Не обрывает а просто запрашивает информацию маленькими порциями.
Range: bytes=305806-312466 - указывает начало и конец фрагмента.
Range: bytes=305806- - продолжить с конкретного места

Цитата:

Сколько же там кусочков будет, тысячи?

Да. Но, как правило, кусочки идут по порядку. Тогда можно их на лету склеивать. Т.е. дописывать в концы файлов а не создавать новые.

C0USIN

Цитата:

Тогда можно их на лету склеивать. Т.е. дописывать в концы файлов а не создавать новые.

Вроде ничего страшного, только непонятно как это отлаживать?

mai62
К именам фрагментов лучше добавлять просто информацию о месте его в полном файле.
Например, дописывать строчку #305806
Так мы узнаем, что фрагмент начинается с позиции 305806 байт от начала. Длину фрагмента узнаем по размеру файла с этим фрагментом. Фрагмент начинающийся с нулевой позиции называем так-же как и сейчас: *.new или лучше *#0

deus6666
Цитата:

канадский проект

Это уже не параллельный, а сравнивать между собой изделия разных Developer Team's всё равно, что сравнивать "северные яйца" и "баранье сияние"

forever
Цитата:

да, на делфи можно скомпилировать юникодный проект

Уважь, укажи путь... Но если проект компилится сторонним компилятором, то при чём здесь Делфи? Типа продвинутый редактор?..

Цитата:

А она существует?

Если ты имеешь в виду философское "существую только я", то конечно же её нет, всё, что вовне - только кажется...

Цитата:

У пользователей НС что-то не так?

Вполне возможно - не все баги запросто наблюдаются глазками, да и проявляться могут лишь в определённых условиях, а в данном случае (надеюсь,- пока) никто не знает - в каких Проблемный модуль - "Библиотека маршрутизации для нескольких служб доступа"

Цитата:

Перемывать кости старому компилятору от борланда просто из любви к процессу имхо занятие бессмысленное

Любовь, морковь... Пустое это! Принимая некую данность в целом (даже трижды замечательную, как в нашем случае) - совсем не обязательно зажмуриваться от восторга. И тогда видно, что петь дифирамбы, как ты говоришь - "старому", но не выросшему из детских штанишек компилятору занятие не менее бессмысленное. Имхо...

Цитата:

Чем распаковываешь PECompact 2.x и какой линк-вьевер пользуешь?

1. Говорил уже - утиль собственного производства. Но зачем вопрос? Как я понял, тебе упаковка нравится...2. Я слегка упростил, назвав это линк-вьюером, на самом деле функционал утилиты "Dependency Walker", входящей в состав SDK для MSVS (и PSDK) несколько шире...

P.S. Оффтопим, друже... Харе на этом...

C0USIN
Дефрагментация наверное полумера. Спрошу по другому. Ось стоит на разделе C а папка с кешем на D, причем в кеше больше количество файлов чем на системном разделе. При увеличении кеша растет или нет файловая система или на D своя MFT и на общую проиводительность системы не влияет? Ведь чем больше MFT тем медленнее винт работает.

NothingAnother

Цитата:

Харе на этом...
Уважь, укажи путь...

Неужто сам запутался в словоблудии?


Цитата:

Но если проект компилится сторонним компилятором

С чего борландовский компилятор стал сторонним?


Цитата:

Вполне возможно - не все баги запросто наблюдаются глазками, да и проявляться могут лишь в определённых условиях, а в данном случае (надеюсь,- пока) никто не знает - в каких Проблемный модуль - "Библиотека маршрутизации для нескольких служб доступа"

Ух, ну и высокое же древо тебе нужно для растекания мыслью. Не легче ли было просто убедиться, что эта "проблемная функция" никоим боком не используется в НС? Восстанавливает подключения к сетевым дискам при старте винды: WNetRestoreConnectionW is used by Winlogon to restore all persistent drive mappings during the interactive logon process.


Цитата:

И тогда видно, что петь дифирамбы, как ты говоришь - "старому", но не выросшему из детских штанишек компилятору занятие не менее бессмысленное.

Какие дифирамбы? О чем ты? То, что ты смотришь, скомпиллированно на семерке, я хочу (хотел) посмотреть на результат десятки.


Цитата:

Говорил уже - утиль собственного производства.

Мысль о багах утиля конечно будет с негодованием отвергнута?

Кстати, не растолкуешь, как же все-таки в MSVC происходит выбор как компилировать проект: в юникоде или в анси? Если я использую какую-либо анси-функцию то она будет автоматом заменена на юникодный аналог?

spec321
Цитата:

Дефрагментация наверное полумера.

Полностью не согласен HC активно обращается к кэшу. При каждом запросе браузера читаются папки. Если диск дефрагментировать регулярно, то все каталоги будут в одном месте и поиск будет работать в разы быстрее.

Цитата:

При увеличении кеша растет или нет файловая система

да, но на диске D

Цитата:

или на D своя MFT и на общую проиводительность системы не влияет?

да

Цитата:

Может преобразовать папку кеша в виртуальный диск? Какую программу для этого использовать? А может кто предложит другой путь

Может дефрагментация поможет?

p.s. сорри за повтор, пока ветку прочитаешь, забудешь о чем хотел написать. Жаль, что на таком продвинутом форуме нет кнопки 'удалить сообщение'.

spec321

Цитата:

Может преобразовать папку кеша в виртуальный диск? Какую программу для этого использовать?

Виртуальный диск создал программой VdfCrypt, закинул весь кеш на виртуалку. Доволен как слон

C0USIN

Цитата:

Те-же яйца. Вид сбоку. Только скорость ухудшится.

Тормоза замечал лишь при открытии Тоталом папки кеша, но я очень сомневаюсь, что на реальном разделе тормозить будет меньше. На конфигурации средней по тепершним меркам (Cel D 2.1 , 512 RAM) тормоза не замечены.

Вообще, от виртуалки преимуществ намного больше, чем недостатков. Право, это же не игрушка в конце-концов, где за каждый FPS борешься...

Насчёт виртуального диска...
Можно сделать проще.
- Написать батник со следующего содержания:

Код: subst X: C:\Cache

S0ldier
Ты это серьезно?

C0USIN
Да ладно тебе, неужели и впрямь подумал, что этот бред кто-нить воспримет всерьёз? Ясен пень, чек прикалывается... Вот только почему-то смайликов не видно...

C0USIN
Ну как можно такое подумать?

Добавлено:
А если серьёзно - то для хранения кэша хорошо BestCrypt использовать.

C0USIN
spec321
Насчёт фрагментации:
есть замечательная программка Марка Руссиновича contig, с помощью которой можно исследовать фрагментацию и производить дефрагментацию отдельных файлов или каталогов (которые на NTFS эквивалентны файлам, наколько я понимаю). Например, чтобы выяснить среднее число фрагментов на файл в папке HandyCache, я выполняю команду:
contig -a -s D:\PROGRAMS\HandyCache\Cache
Для дефрагментации папки HandyCache, соответственно,
contig -s D:\PROGRAMS\HandyCache\Cache

Кроме того, где-то в реестре Windows есть параметр, который определяет минимальную длину свободного пространства на диске, которую ищет система при создании файла на NTFS-разделе. Можно выставить этот параметр, например, в 1 Мб, и тогда в папке HandyCache вообще файлы фрагментироваться не будут.

И ещё один важный, на мой взгляд, вопрос: тут выше casm82 22:47 01-10-2006 провёл эксперимент, сравнил скорость чтения и записи на обычный и сжатый NTFS-раздел. Получилось, что со сжатым разделом работа происходит быстрее. В связи с эти ряд вопросов: фрагментация при работе со сжатым разделом накапливается так же, как и c обычным, или всё-таки быстрее? Насколько правильно был проведён его эксперимент? Поиск файла на сжатом разделе происходит так же, как на обычном или медленнее? Как наиболее правильно это оценить? Какой оптимальный размер кластера будет в нашем случае (эффективность сжатия на NTFS-разделах сильно зависит от размера кластера).

S0ldier
Мне непонятно, зачем шифровать кэш? Эти проги умеют создавать контейнеры без шифрования?

popkov

Цитата:

фрагментация при работе со сжатым разделом накапливается так же, как и c обычным, или всё-таки быстрее?

Думаю что так-же.

И на поиск файла сжатие влиять не должно. MFT ведь не сжимается.

C0USIN
Цитата:

Думаю что так же. И на поиск файла сжатие влиять не должно. MFT ведь не сжимается

Значит, нет никаких причин не сжимать папку HandyCache? Сжатие в данном случае принесёт только пользу?
А какой размер кластера будет оптимален для сжатого раздела, на котором хранятся сотни тысяч маленьких файлов?

C0USIN
Есть программы, создающие диски и без шифрования.
А шифровать затем, чтобы не узнали враги

popkov
Цитата:

А какой размер кластера будет оптимален для сжатого раздела, на котором хранятся сотни тысяч маленьких файлов?

Я не уверен про сжатие MFT, кстати. Файлы меньше 1кб будут целиком лежать в записях MFT. Будут ли они тогда сжиматься?
А размер кластера должен быть не больше килобайта.

popkov

Цитата:

Значит, нет никаких причин не сжимать папку HandyCache? Сжатие в данном случае принесёт только пользу?

Как использовать сжатие файлов в Microsoft Windows XP

Цитата:

При открытии сжатого файла Windows автоматически распаковывает его для Вас, а при закрытии снова сжимает. Данный процесс может снизить производительность Вашего компьютера.

Best practices for NTFS compression in Windows

Цитата:

Because NTFS compression is processor-intensive, the performance cost is more noticeable on servers, which are frequently processor-bound. Heavily loaded servers with a lot of write traffic are poor candidates for data compression.

Файловая система NTFS

Цитата:

Сжатие осуществляется блоками по 16 кластеров

popkov

Цитата:

Значит, нет никаких причин не сжимать папку HandyCache? Сжатие в данном случае принесёт только пользу?

графика (jpeg, gif, png) как правило не сжимается. Если страницы запакованы в gzip, они тоже не ужмутся. При таком раскладе выйгрыш по размеру будет небольшой => производительность может даже пострадать.

У кого кеш на сжат средсвами NTFS? Напишите сюда на сколько получилось ужать.

Цитата:

У кого кеш на сжат средсвами NTFS? Напишите сюда на сколько получилось ужать.

Общий размер - 900 Мб
Размер на диске - 676 Мб.
Т.е. у меня экономия 25%

forever
Цитата:

При открытии сжатого файла Windows автоматически распаковывает его для Вас, а при закрытии снова сжимает. Данный процесс может снизить производительность Вашего компьютера.

Насколько я понимаю, файл при открытии распаковывается в оперативную память, при этом на диске он остаётся тем же. А при закрытии он запаковывается в оперативной памяти, и записывается на диск в упакованном виде. Это наиболее логично и естественно, даже для Microsoft. Поэтому распаковка совершенно не должна нагружать винчестер, да и процессор тоже, поскольку алгоритмы чрезвычайно примитивны (хотя детально я их не изучал).

Цитата:

Because NTFS compression is processor-intensive, the performance cost is more noticeable on servers, which are frequently processor-bound. Heavily loaded servers with a lot of write traffic are poor candidates for data compression.

Это более понятно: сжатие и запись на диск должны занимать больше ресурсов винчестера и процессора, чем чтение с диска и распаковка в оперативную память.

Хотя, наверное, точно выяснить всё это можно только путём постановки эксперимента (и более детального изучения работы NTFS, в частности, при сжатии одной папки на разделе, MFT, видимо, не сжимается? а при создании сжатого раздела MFT сжимается или нет?