привет.
вот мысль меня посетила.
а почему бы например не написать драйвер — файловый фильтр, который бы делал следующее:

1. при запуске системы подгружает содержимое часто используемых файлов в заранее зарезервированную область памяти ("кеш")
2. при изменении этих файлов (*SetInformation, *Write, ...) обновляет внутренний "кеш"
3. при запросах содержимого этих часто используемых файлов (*Read, *QueryInformation, ...) отдаёт данные из "кеша"

часто используемые файлы — это например System32\*.exe, System32\*.dll, а также исполняемые модули программ, которые запускаются вместе с Windows.

вопросы:

1. как считаете, намного ли ускорит работу дисковой подсистемы подобный драйвер?
2. с какими подводными камнями можно столкнуться при реализации такой схемы?
3. существуют ли подобные разработки? где можно скачать?
4. был ли у вас опыт подобной разработки? как ощущения?

спасибо заранее.

А>3. существуют ли подобные разработки? где можно скачать?

здесь

Здравствуйте, Аноним, Вы писали:

А>вот мысль меня посетила.
А>а почему бы ...

А сейчас так примерно и происходит.

А>1. как считаете, намного ли ускорит работу дисковой подсистемы подобный драйвер?
в большинстве сценариев — да

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

А>3. существуют ли подобные разработки? где можно скачать?
их давно уже начали встраивать прямиком в ОС:
Windows Vista: тесты SuperFetch и ReadyBoost

Первая версия встроена в XP и ее зовут Prefetch

А>4. был ли у вас опыт подобной разработки? как ощущения?
зачем подобной? подобной — пусть работают те, кому по штату положено. вот вокруг их работы, бывает, что-то случается конечно. А ощущения же по идее не должны сильно отличаться от любых других обычных в нашем деле — требования, дизайн, кодирование, тестирование.

А>>1. как считаете, намного ли ускорит работу дисковой подсистемы подобный драйвер?
VAB>в большинстве сценариев — да

Отлично. Значит есть повод напедалить нечто подобное.

А>>2. с какими подводными камнями можно столкнуться при реализации такой схемы?
VAB>весь джентльменский набор камней разработчика режима ядра, несомненно, будет в наличии

Я имел в виду подводные камни не при написании собственно драйверов, а скорее при проектировании такого механизма кэширования.

VAB>их давно уже начали встраивать прямиком в ОС:
VAB>Первая версия встроена в XP и ее зовут Prefetch

Да, я знаю. Но я имел в виду несколько другое. Минусы этого префетча очевидны:

Кеш будет автоматически уменьшен, если какой-либо программе будет не хватать памяти. Хотелось бы чтобы такое поведение было настраиваемым.

Более старые данные будут вытеснены из кэша более новыми. В этом случае вся эффективность кэша сводится к нулю.

Хотелось бы реализовать такой кэш, данные в котором находились бы постоянно. Ну и гибкую систему настроек разумеется.
Я думаю это будет хороший выход для тех у кого недостаточно шустрая дисковая подсистема, но достаточно памяти, ведь даже при 1 ГБ ОЗУ такая схема должна по идее давать прирост производительности на XP, для Vista конечно от 2 ГБ надо бы.

А>>4. был ли у вас опыт подобной разработки? как ощущения?
VAB>зачем подобной? подобной — пусть работают те, кому по штату положено. вот вокруг их работы, бывает, что-то случается конечно.

И то верно.

VAB>А ощущения же по идее не должны сильно отличаться от любых других обычных в нашем деле — требования, дизайн, кодирование, тестирование.

Понял, спасибо.

А>>вот мысль меня посетила.
А>>а почему бы ...
AWW>А сейчас так примерно и происходит.

Ну конечно, я не первый кому пришла в голову подобная мысль.
Вот только производительность оставляет желать лучшего, даже имея 2 ГБ ОЗУ.
Про Vista и Server 2008 я вообще молчу.

Здравствуйте, Аноним, Вы писали:

А>1. при запуске системы подгружает содержимое часто используемых файлов в заранее зарезервированную область памяти ("кеш")
А>2. при изменении этих файлов (*SetInformation, *Write, ...) обновляет внутренний "кеш"
А>3. при запросах содержимого этих часто используемых файлов (*Read, *QueryInformation, ...) отдаёт данные из "кеша"

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

А>1. как считаете, намного ли ускорит работу дисковой подсистемы подобный драйвер?

Скорее всего, немного замедлит, т.к. будеть мешать работать встроенному кешу.

Pzz>Оно там уже есть. Правда, не на уровне файлов, а на уровне страниц. Но была бы разница...

Есть. Но работает неудовлетворительно на мой взгляд.

Pzz>Основная проблема заключается в том, как угадать, когда и какие файлы (вернее, страницы) подгружать.

Я планирую банально вынести это в настройки приложения, чтобы пользователь сам мог указать.
К тому же можно придумать алгоритмы, по которым выявлять часто используемые файлы.

Для примера:

Все исполняемые модули, которые загружают (при старте и в процессе работы) указанные пользователем приложения.

Просто файлы, доступ к которым осуществляется чаще всего, и которые при этом читаются, но не изменяются.

Можно таким образом придать нашему драйверу немного интеллекта.
Короче, есть над чем подумать.

Pzz>Скорее всего, немного замедлит, т.к. будеть мешать работать встроенному кешу.

Встроенный кэш не будет использоваться вовсе.
Запросы на чтение не будут доходить до драйверов файловых систем.

Здравствуйте, <Аноним>, Вы писали:

А>а почему бы например не написать драйвер — файловый фильтр, который бы делал следующее:

А>3. существуют ли подобные разработки? где можно скачать?

Разработки такие существую, вот например некоторые из них — Windows 2000, Windows XP, Windows Vista...