Здравствуйте, CEMb, Вы писали:

CEM>Хочу делать паузы между обращениями к диску на чтение/запись.

Так ведь паузы должна сама программа делать, а не кто-то за нее.

Хотя...

Попробуй следующее. Есть такие функции из ntdll.dll — NTSuspendProcess и NTResumeProcess (XP и выше)

http://rsdn.ru/forum/winapi/746124.1.aspx

Автор: Pavel Dvorkin
Дата: 02.08.04

Вызывай их по таймеру . Может, что-то и получится.

PD>Есть такие функции из ntdll.dll — NTSuspendProcess и NTResumeProcess (XP и выше)

Регистр, блин! Сервисы тупо перечисляют все потоки под локом и делают с каждым запрошенное действие.

NTSTATUS
NtSuspendProcess (
    IN HANDLE ProcessHandle);

NTSTATUS
NtResumeProcess (
    IN HANDLE ProcessHandle);

PD>Вызывай их по таймеру...

В общем-то, не самая удачная идея, т.к. будет заморожено всё, включая UI, а не только дисковые операции, но как вариант, имеет право на существование.

CEM>Вот если бы можно было бы для the программы после каждой записи делать Sleep(20)...

Ну ты понел, да?
Ещё можно хуки на Nt-сервисы в процессе.
И называется это не квота, а регулирование пропускной способности.

Здравствуйте, x64, Вы писали:

CEM>>Вот если бы можно было бы для the программы после каждой записи делать Sleep(20)...

x64>Ну ты понел, да?
x64>Ещё можно хуки на Nt-сервисы в процессе.
А можно по-подробнее или линк?

x64>И называется это не квота, а регулирование пропускной способности.
Ясно.

CEM>А можно по-подробнее или линк?

А что тут рассказывать, всё уже обсуждалось много раз. В ntdll.dll есть переходники NtWriteFile(), NtReadFile() и т.д. Хватай их и вставляй свои задержки, как требуется.

Здравствуйте, CEMb, Вы писали:

5er>>Перехват api-вызовов хорош для тестирования, когда нужно зафейлить системный вызов в готовом приложении и посмотреть реакцию.
CEM>О, интересная идея. А насколько это актуально бывает? Ну и фэйл фэйлу — рознь. Да и зафэйлить можно без перехвата — стек сломать/забить

Актуально бывает редко, в целом. В основном для стресс-тестов кода 24*7*365, приближенного к системным вызовам.
Например, хуки можно использовать для эмуляции сетевых задержек или медленной работы с файловой системой (в хуке простой Sleep)
Довольно быстро обнаруживаются невоспроизводимые при штатной эксплуатации ошибки синхронизации в коде,
который 'думает', что, например, ReadFile всегда будет работать быстро.

Здравствуйте, x64, Вы писали:

PD>>Есть такие функции из ntdll.dll — NTSuspendProcess и NTResumeProcess (XP и выше)

x64>Регистр, блин!



>Сервисы тупо перечисляют все потоки под локом и делают с каждым запрошенное действие.

По крайней мере под локом.

x64>В общем-то, не самая удачная идея, т.к. будет заморожено всё, включая UI, а не только дисковые операции, но как вариант, имеет право на существование.

И на том спасибо

В твоей идее насчет хука NtReadFile и NtWriteFile будет та же заморозка, если ввод-вывод делается в GUI потоке.

PD>В твоей идее насчет хука NtReadFile и NtWriteFile будет та же заморозка, если ввод-вывод делается в GUI потоке.

Тащемта, да, разумеется, но во-первых, в грамотно спроектированном приложении такое недопустимо, во-вторых, всегда можно виртуализовать файловые операции, сделав их асинхронными принудительно, т.е. пришёл запрос на запись, пишем данные в свой внутренний кэш и сразу же возвращаем наверх результат "Успех", а реально данные пишем на диск в отдельном потоке с нужной нам задержкой. Тут только две проблемы: это, скажем так, слегка затратно по времени реализации, и виртуализацию конкретно чтения получится сделать только если файл был изначально открыт для асинхронного ввода/вывода, т.к. мы не сможем сразу вернуть данные с тома, они ведь станут доступны нам только после того, как отработает задержка.

Здравствуйте, CEMb, Вы писали:

CEM>Можно как-то чем-то ограничить объём читаемой-записываемой процессом информации на диск?

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

Q>В висте/семёре появилось несколько ручек для управления приоритетом ввода-вывода. Может, подойдёт?

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

Здравствуйте, x64, Вы писали:

x64>Это не будет работать, если кроме целевого процесса не будет других процессов, которые также интенсивно используют ввод/вывод, т.е. здесь нет принудительного ограничения пропускной способности, это лишь настройка приоритетов по отношению к прочим читателям/писателям, ничего более.

Да, но из описания задачи непонятно, для чего именно нужно ограничивать пропускную способность дискового I/O. Из моей практики, обычно это нужно, чтобы один процесс не забивал другие. Тут приоритизация должна помочь.

[OFF]Дорого бы я дал за такую функциональность для XP. Корпоративные сканеры 3 раза в день подрываются по своим стукаческим делам и отхватывают себе пол-ОЗУ и весь disk i/o. Полчаса можно читать книжку с КПК. [/OFF]

Здравствуйте, x64, Вы писали:

x64>Тащемта, да, разумеется, но во-первых, в грамотно спроектированном приложении такое недопустимо

Судя по всему, ТС досталось не очень грамотно спроектированое приложение

>во-вторых, всегда можно виртуализовать файловые операции, сделав их асинхронными принудительно, т.е. пришёл запрос на запись, пишем данные в свой внутренний кэш и сразу же возвращаем наверх результат "Успех",

Гм, а чтение как ? "Успех" без данных ? Я же в буфер тут же полезу, а что там ?

>а реально данные пишем на диск в отдельном потоке с нужной нам задержкой. Тут только две проблемы: это, скажем так, слегка затратно по времени реализации, и виртуализацию конкретно чтения получится сделать только если файл был изначально открыт для асинхронного ввода/вывода, т.к. мы не сможем сразу вернуть данные с тома, они ведь станут доступны нам только после того, как отработает задержка.

Тут еще одна проблема. Получив ответ "Успех" , приложение решит, что данные и впрямь записаны, после чего, чего доброго, иной поток (а может, и этот же) попробует их прочитать. Будешь контролировать полностью работу кэша и брать данные из него ? А если сюда еще доступ по mmf добавится, то накроется все это медным тазом, если только ты не реализуешь свой собственный кэш всерьез, то есть фактически реализуешь кэш-систему Windows на уровне одного процесса.
И не дай бог есть соседние процессы, котрые с ним синхронизированы по файловым операциям.

Здравствуйте, Pavel Dvorkin, Вы писали:

x64>>Тащемта, да, разумеется, но во-первых, в грамотно спроектированном приложении такое недопустимо

PD>Судя по всему, ТС досталось не очень грамотно спроектированое приложение

Ага. Это (широко известный) aнтивирус, насаждённый сетевой политикой. Причём, я смотрел, скоко он стоит, он у меня на лаптопе был триал-версия, предустановленный. Снёс. За такие деньги это чудо работает так:
— берёт следующий файл и копирует его к себе в папку
— проверяет
— удаляет
Из интересного:
— пофиг чё за файл, жрёт образы виртуалок несколько гиговые. Ну это ладно, хотя вот это дело винт и подсаживает. Представьте, 20 гигов копировать.
— не проверяет сколько свободного места на винте! То есть, копирует до тех пор, пока в ноль всё не съест. После этого, судя по внешним признакам, минут 5-10 пытается упорно копировать дальше. После бросает эту затею и идёт за следующим файлом. 300-400 баксов стоит простая годовая подписка!

>>во-вторых, всегда можно виртуализовать файловые операции, сделав их асинхронными принудительно, т.е. пришёл запрос на запись, пишем данные в свой внутренний кэш и сразу же возвращаем наверх результат "Успех",

PD>Гм, а чтение как ? "Успех" без данных ? Я же в буфер тут же полезу, а что там ?

>>а реально данные пишем на диск в отдельном потоке с нужной нам задержкой. Тут только две проблемы: это, скажем так, слегка затратно по времени реализации, и виртуализацию конкретно чтения получится сделать только если файл был изначально открыт для асинхронного ввода/вывода, т.к. мы не сможем сразу вернуть данные с тома, они ведь станут доступны нам только после того, как отработает задержка.

PD>Тут еще одна проблема. Получив ответ "Успех" , приложение решит, что данные и впрямь записаны, после чего, чего доброго, иной поток (а может, и этот же) попробует их прочитать.

Да, я как раз рассказал, что за прога, потому что записав файл, чудо начнёт его тестить. Я думаю, правильно было бы при чтении ему сразу EOF сказать? Но всё=-таки хотелось бы, чтобы он свою функцию выполнял, т.е. проверял на вирусы. Но мееееедленоооо...

Здравствуйте, quodum, Вы писали:

x64>>Это не будет работать, если кроме целевого процесса не будет других процессов, которые также интенсивно используют ввод/вывод, т.е. здесь нет принудительного ограничения пропускной способности, это лишь настройка приоритетов по отношению к прочим читателям/писателям, ничего более.

Q>Да, но из описания задачи непонятно, для чего именно нужно ограничивать пропускную способность дискового I/O. Из моей практики, обычно это нужно, чтобы один процесс не забивал другие. Тут приоритизация должна помочь.

Не помогает, в том и дело Приоритет в нуль, афинити в один — нифига. Винт светит лампочкой бесперерывно. В критической ситуации делаю суспенд. Но это крайний случай, так как есть подозр, что на этот процесс завязаны другие, нужные мне, и не достучавшись до него тоже ступорятся/частично.

Q>[OFF]Дорого бы я дал за такую функциональность для XP. Корпоративные сканеры 3 раза в день подрываются по своим стукаческим делам и отхватывают себе пол-ОЗУ и весь disk i/o. Полчаса можно читать книжку с КПК. [/OFF]
Вот и мне для XP надо. Походу, надо скинуться и нанять x64() чтоб он накатал нам ту мегасофтину спасительную

PS: процесс без-GUI, окон там нету.

> Вот и мне для XP надо. Походу, надо скинуться и нанять x64() чтоб он
> накатал нам ту мегасофтину спасительную

Под хапе — вам напиши так вы ж потом фидбэком запарите
Под w2k3 sp1+ — уже проще, там FltMgr есть.

PD>Гм, а чтение как ? "Успех" без данных ? Я же в буфер тут же полезу, а что там ?

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

PD>Будешь контролировать полностью работу кэша и брать данные из него ?

Да, разумеется, любой файловый кэш так и работает вообще-то.

PD>А если сюда еще доступ по mmf добавится, то накроется все это медным тазом...

Да нет, MMF на уровне процесса тоже вполне возможно перехватить.

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

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

V>Под w2k3 sp1+ — уже проще, там FltMgr есть.

Ну под XP SP2 он тоже есть, если что.

Здравствуйте, x64, Вы писали:

PD>>Гм, а чтение как ? "Успех" без данных ? Я же в буфер тут же полезу, а что там ?

x64>Я вроде уже написал об этом.

Вот это ?

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

Если да, то это и есть признание того, что работать в общем случае не будет.

x64>Ты, главное, успокойся, никто не говорил, что будет легко.

Я и так спокоен.

PD>>Будешь контролировать полностью работу кэша и брать данные из него ?

x64>Да, разумеется, любой файловый кэш так и работает вообще-то.

Я и говорю — перепишешь менеджер кеша Windows применительно к одному процессу.

PD>>А если сюда еще доступ по mmf добавится, то накроется все это медным тазом...

x64>Да нет, MMF на уровне процесса тоже вполне возможно перехватить.

Именованные MMF всегда потенциально могут быть расшарены.

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

x64>Драйвер-фильтр файловой системы, господа.
x64>Ну и я предупреждал о трудоёмкости, чего теперь удивляться-то?

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

http://rsdn.ru/forum/winapi/4470834.1.aspx

Автор: ononim
Дата: 25.10.11

PD>То, что ты предложишь, было заранее известно

Предложи что-нибудь лучше, я ж не против, у тебя есть другие варианты?

Здравствуйте, x64, Вы писали:

PD>>То, что ты предложишь, было заранее известно

x64>Предложи что-нибудь лучше, я ж не против, у тебя есть другие варианты?

Э!э!э! Ну вы чего?
Я вам дал описало действий программы, будут уточнения по функционалу?