[NTOKSNRL] Always flush dirty VACB.

Recent changes seem to show that it's not
required to be exclusive on VACB to be able
to flush it.

This commit goes with f2c44aa and fixes the
last issues going with copying huge files.
There are no longer BSODs (be it in Mm or Cc).
I could, with 750MB RAM extract a 2GB file from
a 53MB archive and copy a 2,5GB file from a VBox
share to the disk. Note that writes are often
deferred, so if copy works, it's not that fast for now.

Note that it also brings some beloved behavior from
Windows: copy times are totally unreliable now when
writes are deferred. Little remaining times when
actively copying, high remaining times when deferred
writes in action. And goes between both... Sorry! ;-)

https://xkcd.com/612/

CORE-9696
CORE-11175
This commit is contained in:
Pierre Schweitzer 2018-04-30 22:19:17 +02:00
parent 7673837a85
commit 54c049bd6e
No known key found for this signature in database
GPG key ID: 7545556C3D585B0B

View file

@ -207,8 +207,6 @@ CcRosFlushDirtyPages (
while ((current_entry != &DirtyVacbListHead) && (Target > 0))
{
ULONG Refs;
current = CONTAINING_RECORD(current_entry,
ROS_VACB,
DirtyVacbListEntry);
@ -234,17 +232,6 @@ CcRosFlushDirtyPages (
ASSERT(current->Dirty);
/* One reference is added above */
Refs = CcRosVacbGetRefCount(current);
if ((Refs > 3 && current->PinCount == 0) ||
(Refs > 4 && current->PinCount > 1))
{
current->SharedCacheMap->Callbacks->ReleaseFromLazyWrite(
current->SharedCacheMap->LazyWriteContext);
CcRosVacbDecRefCount(current);
continue;
}
KeReleaseGuardedMutex(&ViewLock);
Status = CcRosFlushVacb(current);