LayeredFSD and different support routines for AcquireForReadAhead?

Hi all, I’m learning fastfat source and NT4(Windwos 2000) source recently.
From NT4 source I learn that differnt FS(FastFat, CdFs, NTFS, etc.) have different support routines for AcquireForReadAhead. For example, the support routine for NTFS try to acquire PagingIo Resource, but the support routine for FastFAT try to acquire Main Resource.
How should I handle this problem in my layered filter? Do I need to add different support routines for different FS?

I think you should design the whole locking discipline for your FSD, just having 2 ERESOURCE locks provided to you as memory locations.

You can use FAT’s way, for instance.

With FAT, PagingIoResource is only used to guard truncation (to make a barrier on cache lazy writing during truncation), and is only taken exclusively for truncation.

MainResource is used for any EOF updates.

Since paging IO (lazy writer included) cannot alter EOF, it does not need to grab MainResouce, it only grabs PagingIoResource shared.

This speeds up a scenario when you have a sequence of tiny file-growing appends (imagine some cmd line tool redirected to a file and doing printf() calls there), together with the lazy writer. The latter can be executed in parallel with any “write and grow” call. “Write and grow” can proceed in parallel with some cache page being in the process of writing out to disk.

Also don’t forget about AcquireForCreateSection, which is used by Cc/Mm to guard the pointer assignments to SECTION_OBJECT_POINTERS.


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntfsd…
> Hi all, I’m learning fastfat source and NT4(Windwos 2000) source recently.
> From NT4 source I learn that differnt FS(FastFat, CdFs, NTFS, etc.) have different support routines for AcquireForReadAhead. For example, the support routine for NTFS try to acquire PagingIo Resource, but the support routine for FastFAT try to acquire Main Resource.
> How should I handle this problem in my layered filter? Do I need to add different support routines for different FS?
>

The model is sufficiently general that you can implement this as appropriate for your driver. You should NOT care how the file system below you implements its logic. I will caution you, however, that the most deadlock-free design will be the one in which you never hold locks while calling the underlying file system. This is a challenging paradigm, but ensures that none of the odd re-entrancy cases you will see cause deadlocks on your locks. The challenge of course is that if you don’t lock data structures across such calls they can change and you must be able to handle such changed.

Tony
OSR

I read the source code of fastfat again, but I can not quite understand .
The CACHE_MANAGER_CALLBACKS will acquire the resource(may be MainResource, may be PagingIoResource), and then my filter get a PagingIo Read request. If I send this request to the lower file system, how can I never hold locks while calling the underlying file system?