If you specify PAGING_IO flag, it can’t read from the cache. That’s the point of the PAGING_IO flag (FltReadFile supports this flag!).
xxxxx@gmail.com wrote:
Thanks a lot Sir for clarifying my doubts.
In the same thread, Mr. David said that “Why would it? The file system knows the data is in the cache and will give it to you from there.”…
Does it mean that the FSD can actually use the cache instead of reading the data from the disk?
If it really happens, can you please explain me the reason?
–
Kind regards, Dejan
http://www.alfasp.com
File system audit, security and encryption kits.
Does this mean that when i call FltReadFile with PAGING_IO flag set, a new IRP will be created by the Filter Manager. Will this IRP have TopLevelIrp != NULL, so that the FSD thinks that this request is issued by the CM / VMM and won’t try to acquire the locks again ?
What locks? If you check FastFat source code, during a paging I/O, only lpFileObject->FsContext->PagingIoResource is acquired. There will not be any paging I/O from the CM at that point because CM is already issuing a paging write.
The other scenario is non-paging non-cached write, and that’s not an issue.
xxxxx@gmail.com wrote:
Does this mean that when i call FltReadFile with PAGING_IO flag set, a new IRP will be created by the Filter Manager. Will this IRP have TopLevelIrp != NULL, so that the FSD thinks that this request is issued by the CM / VMM and won’t try to acquire the locks again ?
–
Kind regards, Dejan
http://www.alfasp.com
File system audit, security and encryption kits.
This is what i meant…
Since the original Paging Write request issued is blocked by us, and instead of it we send the Paging Read request.
Since, this is also a paging request, the FSD won’t try to acquire locks ( PagingIoResource )…
Right?
Plus won’t the Filter manager set the TopLevelIrp flag so that the FSD doesn’t attempt to acquire the locks again?
If you want to read/write disk as a response to your FS read/writes - then
please do just the read/writes on underlying disk/volume device, without even
touching the FS or using FltMgr’s functions.
Otherwise, the locking issues start to be uncomprehendable.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntfsd…
> This is what i meant…
> Since the original Paging Write request issued is blocked by us, and instead
of it we send the Paging Read request.
> Since, this is also a paging request, the FSD won’t try to acquire locks (
PagingIoResource )…
> Right?
> Plus won’t the Filter manager set the TopLevelIrp flag so that the FSD
doesn’t attempt to acquire the locks again?
>
> If you want to read/write disk as a response to your FS read/writes - then
please do just the read/writes on underlying disk/volume device, without even
touching the FS or using FltMgr’s functions.
You can actually read/write from/to the file system. I don’t recall the fine details. However, you can issue an IRP to read/write a file in the paging I/O path. There are a bunch of things that you need to be careful with. For instance, if you are doing paging I/O, you should make sure that your I/O sizes are not trying to read into non-aligned sizes in the FS. (Again, I don’t recall the details here.) However, my point is that this is doable and allowed.
Thanks Maxim Sir,
Are you proposing to use FSCTL_GET_RETRIEVAL_POINTERS and stuff?
Basically get the LBA ultimately and read data from there?
Am i right?
If yes then, couldn’t a problem come if at the same time someone is trying to defragment the hard disk?
> Since the original Paging Write request issued is blocked by us, and instead of it we send the Paging Read request.
Since, this is also a paging request, the FSD won’t try to acquire locks ( PagingIoResource )…
Right?
Wrong. Again after what? The write request did NOT go down to the FS level yet. The FS would acquire the same
locks for your Read request as it would for CM’s Write request that you are “converting” into Read before you revert it
back into Write.
The logic here is not whether TopLevelIrp is NULL or not - but if the paging write was already sent, a paging
read would also be possible.
–
Kind regards, Dejan
http://www.alfasp.com
File system audit, security and encryption kits.
Sir you said that “The FS would acquire the same locks for your Read request as it would for CM’s Write request that you are “converting” into Read before you revert it back into Write.”…
But as far as i know, if its a paging i/o request, TopLevelIrp is set (NOT NULL). And this indicates that the FS locks have already been acquired, and the FSD need not acquire it again.
I think TopLevelIrp != NULL is an indication that those locks have already been acquired. However, the FSD may also be checking for the PAGING_IO flag and hence not trying to re-acquire the locks…
Right?
How about looking at the FastFat source code instead of asking again and again?
xxxxx@gmail.com wrote:
Sir you said that “The FS would acquire the same locks for your Read request as it would for CM’s Write request that you are “converting” into Read before you revert it back into Write.”…
But as far as i know, if its a paging i/o request, TopLevelIrp is set (NOT NULL). And this indicates that the FS locks have already been acquired, and the FSD need not acquire it again.
I think TopLevelIrp != NULL is an indication that those locks have already been acquired. However, the FSD may also be checking for the PAGING_IO flag and hence not trying to re-acquire the locks…
Right?
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@alfasp.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
–
Kind regards, Dejan
http://www.alfasp.com
File system audit, security and encryption kits.
Nice suggestion…
Will do that…
Thanks once again Sir…
I cannot speculate about all consequences, but maybe possible way how to get out of APC_LEVEL is do job in worker thread and wait for result by KeWaitForSingleObject(). The APC_LEVEL is not processor wide level but thread specific. When scheduler cannot plan any thread at APC_LEVEL (because of waiting state) it will plan for execution also PASSIVE_LEVEL threads.
That will cause problems. The fundamental thing that you cannot do in a paging i/o write when the system is trying to clear up memory is to cause the system to allocate memory…which you will do if you submit normal i/o in this path.
-----Original Message-----
From: … On Behalf Of xxxxx@xythos.com
Sent: Wednesday, September 05, 2007 9:27 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Reading in Paging I/O Path
I cannot speculate about all consequences, but maybe possible way how to get out of APC_LEVEL is do job in worker thread and wait for result by KeWaitForSingleObject(). The APC_LEVEL is not processor wide level but thread specific. When scheduler cannot plan any thread at APC_LEVEL (because of waiting state) it will plan for execution also PASSIVE_LEVEL threads.