site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com I'd like to come at this problem a little differently. Godfrey On 11/10/2006, at 04:08 , Alison Cassidy wrote: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... Are you a kernel hacker? It may be possible to modify the IOMediaBSDClient to stall I/O's for a few seconds until a convenient time in the future, this should work without to many problems. It seems to me that this is what you are really trying to do? Is that correct? In any case, from that man page, I don't see how you can do both of "quiet all disk activity" and avoid the problem I mention above (which really isn't specific to your process; modern OSs have a lot of processes that can fire at any time to handle the exigencies of the moment; they need to be able to run, or the system crumbles). Right. I'll never quiet *all* disk activity; all I can hope for is to minimize it somehow. You could, as mentioned earlier in this thread, avoid enabling the paging daemon. With sufficient memory, you could run a full system, but things may start failing in strange ways without the elasticity provided by a backing store. In case you haven't looked in depth at the Mac OS X VM system, it's all handled by the paging daemon. There is no path to disk (for this purpose) within the kernel. Right (and thanks John and Graham for the info there). I'd considered messing about with dynamic_pager but wouldn't like to modify the boot args nor kill it outright for very obvious reasons. I need to look into the workings of the paging daemon some more ... This email sent to site_archiver@lists.apple.com