From: Jamey Kirby [jkirby@storagecraft.com] Sent: Wednesday, June 09, 1999 11:17 PM To: Blair Murri; Donald Burn; Yogita Bijani Cc: ntfsd@atria.com; ntdev@atria.com Subject: RE: [ntfsd][ntdev] is there a limit to how many write requests can be handled at a time ? I had a disk filter driver that queued IRPs to system worker threads (work queue items). There was an occasional deadlock that I was epxerienceing. The problem was that there was a condition where a wite and a read were both pending; one dependant on the other completing (don't remember off hand if it was the read dependent on the write or visa versa). Anyway, since there are a limited number of system worker threads, I had a situation where the FSD had used all of the worker threads but one, one of my requests claimed the last one and subsequently, my other request could not get any thread time because it was in the worker thread queue managed by the kernel. My solution was to create a private worker thread using PsCreateSystemThread() for both the write queue and the read queue. This way, there was no contention for system worker threads between the reads and writes. Problem solved, code works and client is happy :) -----Original Message----- From: Blair Murri [mailto:BMurri@wavephore.net] Sent: Wednesday, June 09, 1999 7:29 PM To: 'jkirby@storagecraft.com'; Donald Burn; Yogita Bijani Cc: ntfsd@atria.com; ntdev@atria.com Subject: RE: [ntfsd][ntdev] is there a limit to how many write requests can be handled at a time ? I don't think that adding in your own system thread would work. What would it due?. Here's the situation: NTFS, using a system thread, sends a request for a write and Yogita queues it returning STATUS_PENDING. NTFS, seeing that the result was STATUS_PENDING, waits that calling thread on the i/o operation. (My assumption, I don't really know) NTFS, using another thread, repeats the above until there are no more system threads usable by NTFS. Maybe the reason that the problem doesn't manifest itself with writes to a volume, but does on a partition, has to do with the context of the writes. (volume writes happen in some process thread, while partition writes happen in some system thread, for instance). NTFS must be waiting for the i/o instead of reusing the thread for some other i/o until the first is done. (doesn't seem very scalable to me). The solution has to involve either telling NTFS to use more threads, or to complete the processing faster somehow, or to not do whatever it is that you are doing on partition requests, but only on volume requests. It's tough to say. Just my 2 cents worth. Blair L. Murri Sr. Programmer/etc. Wavo Corporation -----Original Message----- From: Jamey Kirby [SMTP:jkirby@storagecraft.com] Sent: Wednesday, June 09, 1999 5:21 PM To: Donald Burn; Yogita Bijani Cc: ntfsd@atria.com; ntdev@atria.com Subject: RE: [ntfsd][ntdev] is there a limit to how many write requests can be handled at a time ? A simple solution is to use your own worker thread. -----Original Message----- From: owner-ntfsd@atria.com [mailto:owner-ntfsd@atria.com]On Behalf Of Donald Burn Sent: Wednesday, June 09, 1999 10:57 AM To: Yogita Bijani Cc: ntfsd@atria.com; ntdev@atria.com Subject: Re: [ntfsd][ntdev] is there a limit to how many write requests can be handled at a time ? I suspect you are running into the limit of the number of worker threads in the system. I you are pending the requesting thread with from the filesystem there is a reasonable chance it is a system worker thread, since these are very limited in number, you will quickly lock the system. Don Burn Yogita Bijani wrote: Hi! I am writing a filter driver below FSD which blocks write requests on one partitionfor sometime and then releases it after a while. Following are the steps In IRP_MJ_WRITE handler- IoMarkPending(Irp)- queue IRP in a device Driver queue- return STATUS_PENDING In IRP_MJ_DEVICE_CONTROL handler- On receiving a Control Code, send write request details to User Process- On receiving another Control Code , dequeue the IRP and IoCallDriver() I have posted this query before and after trying to investigate on each of thesuggestions, I have come to this conclusion the user mode application is trying to write to a file on some other partition,partition y, where I am not doing anything - no blocking , not even attaching tothat partition. But still the writes to a file on partition y are getting affected by myblocking writes on partition x. this leads to a deadlock and a system state which looks like a hang but actually it isonly the write requests which are getting blocked Same problem does not happen if instead of a file on partition y, the user applicationis writing to a Volume itself ( using \\.\y: ) Any idea what could be the reason, what kind of limit is being reached, if any, andwhy doesn't it affect a Volume write ? Is it to do with some implementation details of ntfsd ? waiting for suggestions, thanks a lot yogita