Hi all,
I have a file system driver (not a filter) which uses a different file system as storage. So I have my own file objects and I deal with the cache manager directly.
To get the data from the media (IRP_NOCACHE) I currently build a new IRP using IoBuildAsynchronousFsdRequest to send to the underlying file system.
I’ve been wondering about using the same IRP to do that. Suppose the Cache Manager needs to flush data, it’d send an IRP to my FSD, I’d change the File Object and Device Object (taking care about the device stack size and top level IRP) and send the same IRP I received from the cache manager to the underlying FSD. That would save some time required to deal with a new IRP creation and deletion.
I saw that this is possible on this post:
http://fsfilters.blogspot.com.br/2011/09/file-io-redirection-between-volumes.html
“In a legacy filter this can be achieved by changing the IO_STACK_LOCATION parameters (like the FileObject) and by sending the IO to a different device when calling IoCallDriver to send the IRP below.”
But I’m wondering about manipulating IRP flags.
Can I just clear/set bits like IRP_NOCACHE, IRP_PAGING_IO, IRP_ASSOCIATED_IRP and so on?
And what about the performance gain? Would that worth?
Thanks in advance,
Fernando Roberto da Silva
DriverEntry Kernel Development
http://www.driverentry.com.br
While this is possible, I wouldn’t think it would gain you very much, if
anything other than complexity. The biggest issue being not having
enough stack locations remaining in the Irp. You can’t just reset the
stack location to the first stack location without doing a lot of
processing like saving off the current information in all the stack
locations that have already been setup. If you don’t reset the stack
location then the case where the Irp will contain enough slots to handle
the entire underlying stack as well will be few, at best. I would
recommend just re-allocating an irp and sending them along.
Pete
On 11/22/2012 8:58 AM, xxxxx@driverentry.com.br wrote:
Hi all,
I have a file system driver (not a filter) which uses a different file system as storage. So I have my own file objects and I deal with the cache manager directly.
To get the data from the media (IRP_NOCACHE) I currently build a new IRP using IoBuildAsynchronousFsdRequest to send to the underlying file system.
I’ve been wondering about using the same IRP to do that. Suppose the Cache Manager needs to flush data, it’d send an IRP to my FSD, I’d change the File Object and Device Object (taking care about the device stack size and top level IRP) and send the same IRP I received from the cache manager to the underlying FSD. That would save some time required to deal with a new IRP creation and deletion.
I saw that this is possible on this post:
http://fsfilters.blogspot.com.br/2011/09/file-io-redirection-between-volumes.html
“In a legacy filter this can be achieved by changing the IO_STACK_LOCATION parameters (like the FileObject) and by sending the IO to a different device when calling IoCallDriver to send the IRP below.”
But I’m wondering about manipulating IRP flags.
Can I just clear/set bits like IRP_NOCACHE, IRP_PAGING_IO, IRP_ASSOCIATED_IRP and so on?
And what about the performance gain? Would that worth?
Thanks in advance,
Fernando Roberto da Silva
DriverEntry Kernel Development
http://www.driverentry.com.br
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
Hi Pete,
About the stack locations, since my device object is in the bottom of the device stack, I was thinking of setting the DeviceObject->StackSize with some extra slots after creating my device, so that any IRP would come with more stack locations. In the worst case, a new IRP would be allocated.
But since this seems to not result on a significant gain, I’ll probably keep the way it is.
Thanks,
Fernando Roberto da Silva
DriverEntry Kernel Development
http://www.driverentry.com.br
Sure, you could grab the stack size from top of the storage stack device
object and go from there but I wouldn’t think it would buy you very much.
Pete
On 11/22/2012 10:19 AM, xxxxx@driverentry.com.br wrote:
Hi Pete,
About the stack locations, since my device object is in the bottom of the device stack, I was thinking of setting the DeviceObject->StackSize with some extra slots after creating my device, so that any IRP would come with more stack locations. In the worst case, a new IRP would be allocated.
But since this seems to not result on a significant gain, I’ll probably keep the way it is.
Thanks,
Fernando Roberto da Silva
DriverEntry Kernel Development
http://www.driverentry.com.br
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
> And what about the performance gain? Would that worth?
I would say no. IoAllocateIrp is neglectable compared to actual disk IO, and, from the architectural point of view, it is always better to never mix the incoming IRPs and the IRPs created by you.
This is a classic sample of micro-optimizing.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com