NTFS and CcDeferWrite ( Bug )

NTFS and CcDeferWrite

Known that CcDeferWrite can call PostRoutine before it returns, while
CcCanIWrite returns false. If it was the case then NTFS will try write
request immediately after CcDeferWrite returns, instead of queueing the
request to system worker thread. But if request is already working at
system worker thread, then NTFS can loop forever because PostRoutine is
being called while CcDeferWrite calling but CcCanIWrite keeps return false
meanwhile.

I discovered it while developing encryption file system. The matter is my
FS direct i/o to real files instead of volume. My FS also interacts with
Memory Manager and Cache Manager, so on paging i/o requests i send
read/write to real file with disabled buffering. On async request
completion, my completion routine queues work to system thread to continue
my original paging request. On stress using of Cc, there can be a case when
NTFS executes buffered write request at system worker thread, and
CcCanIWrite returns false but CcDeferWrite calls PostRoutine immediately.
Meanwhile
my FS has already sent i/o request on paging i/o, and async completion
routine queues work to system worker thread to complete my paging i/o. It
can be a thread where NTFS already loops for CcCanIWrite will return true.
Because of NTFS loops in its write function, it blocks dequeuing my work
which will complete my paging i/o, and because of this request isn’t
completed, CcCanIWrite keeps return false. Therefore it results in 100%
processor loading and NTFS blocks system worker thread.

I solved this issue by creating dedicated thread to which i queue work
which completes paging i/o, but i consider this as NTFS bug.

It’s been there since day one, so while you might claim it to be an NTFS bug, it’s not likely to ever “go away”. The correct way to do this, in my experience, is to treat the system work queues as belonging to *the system* and never using them for your own. Internally, we have done a lot of work on constructing our own efficient work queues, as I’ve found that work queues have a tendency to proliferate, and using the system work queues seldom leads to proper behavior.

Notice that Windows (as of 8.1) now contains *eight* different work queues as part of its standard work queue as well as a number of private work queues, some of which date back to the beginning of Windows NT.

Tony
OSR

I completely agreed with you, but things like these can potentially
interfere working of other drivers. That’s why i told about it. It’s not
first bug i found in NTFS.

2014-10-17 21:19 GMT+04:00 Tony Mason :

>


>
> It’s been there since day one, so while you might claim it to be an NTFS
> bug, it’s not likely to ever “go away”. The correct way to do this, in my
> experience, is to treat the system work queues as belonging to the system
> and never using them for your own. Internally, we have done a lot of work
> on constructing our own efficient work queues, as I’ve found that work
> queues have a tendency to proliferate, and using the system work queues
> seldom leads to proper behavior.
>
> Notice that Windows (as of 8.1) now contains eight different work queues
> as part of its standard work queue as well as a number of private work
> queues, some of which date back to the beginning of Windows NT.
>
> Tony
> OSR
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> 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