Re[2]: Lazy writer thread hang in MiWaitForPageWriteCompletion

NTFSD
1

You could walk through the NTFS handler in WinDbg. That would give you
an idea of how to handle different cases, though maybe not all are
relevant to your application.

Pete

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com http:</http:>
866.263.9295

------ Original Message ------
From: xxxxx@billz.fastmail.fm
To: “Windows File Systems Devs Interest List”
Sent: 4/13/2016 12:40:47 PM
Subject: RE:[ntfsd] Lazy writer thread hang in
MiWaitForPageWriteCompletion

>Hmmm… the more I think about it the more I am wondering if I should
>just return STATUS_CANT_WAIT or other error code in my
>AcquireForModWrite callback when I cannot get the resource.
>Unfortunately fastfat does not have this callback so no clear guidance
>here.
>
>
>—
>NTFSD is sponsored by OSR
>
>
>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>software drivers!
>Details at http:
>
>To unsubscribe, visit the List Server section of OSR Online at
>http:</http:></http:>

2

> 2. An IRP_MJ_CREATE for the file currently locked by the LazyWriter is currently pending and

cannot complete because it cannot acquire the file’s Main resource.

Why are you acquiring Main resource in lazy writer?

Isn’t Paging resource not enough? more so, it must be acquired shared, not exclusively. File truncation is the only path which acquires Paging exclusively.

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

3

>resource. Unfortunately fastfat does not have this callback so no clear guidance here.

Then remove your callback from your code, and do exactly as fastfat does.

Fastfat works :slight_smile:

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

4

> Why are you acquiring Main resource in lazy writer?

Isn’t Paging resource not enough? more so, it must be acquired shared, not
exclusively. File truncation is the only path which acquires Paging exclusively.

The main answer is that my FSD has its own locking requirements that differ from those of FastFat. I may relax some of these locking requirements in the future, but at this stage of development and testing I would rather overprotect my data structures rather than the opposite.

In any case for future reference: the AcquireForModWrite callback should only try to acquire resources with a Wait of FALSE and when it succeeds it should place the acquired resource in *ResourceToRelease and return STATUS_SUCCESS. When it fails it should set *ResourceToRelease to 0 and then return STATUS_CANT_WAIT.

Bill

5

BTW, Maxim, if you (or anyone else) has a comprehensive list of how FastFat does its locking I would love to see it. I have gathered my own list, but it is by no means complete or authoritative (and it is mostly in my head).

Bill

6

> The main answer is that my FSD has its own locking requirements that differ from those of FastFat.

Why do they differ? Both deal with the extendable streams of bytes, which are the same.

testing I would rather overprotect my data structures

Then live with the deadlocks.

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

7

> BTW, Maxim, if you (or anyone else) has a comprehensive list of how FastFat does its locking I

would love to see it.

I never had such a list, which is rather easily constructible from the source.

Also, try reverse-engineering FsRtlCopyRead/Write.

But what I know for sure: at least in old w2k/XP era FASTFAT only used PagingIoResource to synchronize lazy writer with file truncates (to prevent truncating the file tail with in-progress lazy writes on it).

The only place in the code where that lock was taken exclusively was the truncate path. Paging IO, including lazy writer, was taking it shared.

MainResource is a different song.

And, surely, the secone ERESOURCE was invented by MS to prevent the scenario where lots of tiny extending writes to the tail (say “mycmd > file.txt”) will be competing on the same lock with the lazy writer on the same file. This would kill the performance.

With the MS’s smart idea of having 2 locks, the extending writes only take MainResource, while the lazy writer only takes PagingIoResource, so they can run in parallel.

I have gathered my own list, but it is by no means complete or authoritative

What is authoritative is the source, and your list is also such if you trust your own diligence in gathering it.

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