1

A call to IRP_MJ_QUERY_INFORMATION is generated by functions such as Win32's GetFileInformationByHandle or the kernel-mode ZwQueryInformationFile.

Could somebody explain to me what is actually happening with this call? Assuming that I have a traditional 7200RPM magnetic storage HDD.

I know that a lot of the delays when reading from magnetic, rotating drives is due to seek times, but IRP_MJ_QUERY_INFORMATION calls seem very quick in my application. I've checked the contents of the prefetch cache and I couldn't see the file it's querying in there. I'm guessing it's being cached somewhere in memory as the calls are numerous but resolve very quickly and I'm not seeing much HDD activity (although I could be wrong). What actually happens in these situations? Is the file being cached somewhere else by Windows? If so, how can I see it?

I know there's a HDD cache too, but my understanding is that acts more like a buffer for read-aheads etc.

Edit: I was reading this article on MSDN and it suggests that "File system metadata is always cached.", I am assuming this means that if you open a file and make modifications to it, metadata such as "Last Modified Date" won't be committed to disk until you flush the file buffer. In my case, I'm querying a file so I don't need to make any changes to the metadata. Does Windows cache the metadata after the first query for information made by my program?

Community
  • 1
  • 1
Nathan
  • 1,445
  • 9
  • 20
  • You should very much hope so, because some programs do literally thousands of IRP_MJ_QUERY_INFORMATION calls. (In other words: yes) – Damon Nov 27 '12 at 00:48
  • Yeah I've seen some programs do thousands of these calls per second, so it would have to be cached somewhere. I'd like to know some more information about what actually happens behind the scenes though. – Nathan Nov 27 '12 at 00:53

1 Answers1

1

It all depends on the file system involved and sort of information being retrieved. Let's talk about NTFS. :)

When a file is opened, much of the information contained in the directory entry and in the file record for the file is cached in a data structure (called a FCB) that is associated with the handle.

When IRP_MJ_QUERY_INFORMATION is called, this information is copied out from the FCB into the user's buffer. However things like retrieving reparse tags require going back to the original file record and reading that info out. Most of the time, that record is resident in the cache (since it's accessed when the file itself is opened).

MJZ
  • 1,074
  • 6
  • 12
  • Thanks MJZ. I did some reading and I am assuming you are talking about file handles, as FCB's seem to be DOS era. So the metadata is cached after the first time you read it from the file handle? Is there any way to see the contents of this cache? – Nathan Nov 28 '12 at 23:46
  • I found a utility called RAMMap by SysInternals, they're just full of useful utilities, aren't they? It has given me a good visualization of kernel memory maps and I now have a much better understanding of the concept. – Nathan Nov 29 '12 at 04:30
  • Handles are userspace things. Through a per-process kernel table, they map to things called FILE_OBJECT's in the kernel. Individual file systems tack on their own data, typically called FCB's. Yes, >some< (most?) metadata is cached by NTFS. It's stored privately and, beyond using kernel debuggers, there's no way to examine this directly beyond using the NtQueryInformationFile API. – MJZ Nov 30 '12 at 17:26