In the lazy writer run, first post items that are queued for this.
Only then, start executing deferred writes if any.
If there were any, reschedule immediately a lazy writer run, to keep
Cc warm and to make it unqueue write faster in case of high IOs situation.
To make second lazy writer run happen faster, we keep our state active to
use short delay (1s) instead of standard idle (3s).
ScControlService:
- SEH-protext the calls to service control handlers.
- Return ERROR_EXCEPTION_IN_SERVICE if a service control handler throws an exception.
- Return ERROR_SERVICE_CANNOT_ACCEPT_CTRL if no service control handler has been registered for the service.
- RI_ScSetServiceBitsA: Just call RI_ScSetServiceBitsW.
- RI_ScSetServiceBitsW: Store the service bits in the service list entry.
TODO: Merge all service bits in a global variable and pass it to the server service. Maybe use netapi.I_NetServerSetServiceBits(Ex)?
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
Same mechanism exists in Windows (even their Cc
is way different from ours...) where when Cc is
out of memory (in their case, out of VACB), we
will start scavenge old & unused VACB to free
some of the memory.
It's useful in case we're operating we big files
operations, we may run out of memory where to map
VACB for them, so start to scavenge VACB to free
some of that memory.
With this, I am able to install Qt 4.8.6 with 2,5GB of RAM,
scavenging acting when needed!
CORE-12081
CORE-14582
Before any write operation that would involve caching, ask
the cache controler whether writing would make it exceed its memory
consumption. If so, queue the write operation for later execution.
In case the write operation can wait, then, the FSD operation will be
halted until the write is allowed.
I could test it successfully by copying huge files from a FAT volume to
another. The write is halted until some portions of the file is written
to the disk.
I could also properly install Qt (SDK) on ReactOS with this and less than 1GB RAM:
- https://www.heisspiter.net/~Pierre/rostests/Qt_OS.png
- https://www.heisspiter.net/~Pierre/rostests/Qt_OS2.png
CORE-12081
CORE-14582
CORE-14313
Adjusting refcount and enabling lazy-write for pinned
VACB makes it actually more efficient, often purging
data to disk, reducing memory stress for the system.
This is required for defering writes.
This commit unfortunately (?) reverts a previous revert.
CORE-12081
CORE-14582
CORE-14313
- Read the driver settings from the registry.
- Write the driver settings to the registry.
- Make the read-only edit control for the input buffer length look like a non-read-only one because it is controlled by the up-down control.
This is a PoC of what it's possible to realize thanks to an
already existing hack in ntoskrnl :-).
With this extension, on the kdb:> prompt, you're able to type
in commands that will be handled by the FastFAT driver and not
by the kernel, allowing internal debug, not possible otherwise.
So far, three commands exist:
- ?fat.vols: lists all the mounted volumes by FastFAT
- ?fat.files: lists all the files on a specific volume (with their attributes)
- ?fat.setdbgfile: allows watching on specifics files lifetime
This is obviously only the begin and could be greatly improved.
For instance, this is what allowed to debug CORE-14557
- Perform an immediate system shutdown if the timeout is zero, otherwise
display the countdown shutdown dialog.
- Cleanup pShutdownParams->pszMessage as soon as the dialog goes away.
- It actually appears (tested on Windows 2000 and 2003) that sending
WM_CLOSE messages from a user-mode app to the shutdown dialog really
do nothing (and in particular does not cancel the shutdown!), so modify
the code to take this fact into account.
This allows to break commands such as:
C:\ReactOS\system32> for %f in (*.*) do dir
as one would expect: stop the currently running 'dir' and the 'for'.
"bCtrlBreak" doesn't need to be volatile too.
Using CTRL-C to cancel command line input would leave the prompt in
a state where the next command would be ignored. For example:
dir<CTRL-C>
dir
would cause cmd.exe to ignore the second dir command.
CORE-11677
The standard Win32 Console Control Handler will give CTRL-C events to
processes spawned from cmd.exe. If cmd.exe calls GenerateConsolCtrlEvent()
then the child process will receive two CTRL-C events.
Once a directory is crossed (opened or a child is opened), associated
FCB structure is created in FastFAT, but also a stream FO for caching.
Up to now, due to an extra reference taken by the stream file object,
even when the directory was no longer used, the directory was kept in
memory: the FCB was never deleted, the file object was never dereferenced,
and the cache never released.
The immediate effect of this bug is that our FAT driver was leaking every
directory that was used affecting the whole OS situation. In case of
directories intensive operation (like extraction the ReactOS source code
in ReactOS ;-)), we were just killin the whole OS RAM without any way to
release it and recover.
The other side effects: IOs were faster as half of the FS was always
permanant in RAM.
This commit fixes the issue by forcing the FSD to release the FO,
and the cache when a directory is no longer used, leading to its
destruction in RAM.
Downside: on IO intensive operation, expect slowdowns, obviously,
there's less caching now. But more efficient!
CORE-14557
When no name is set in the file object, try to read the name
from the FCB. We only support FastFAT (ours) FCB for now.
This is clearly a hack, but for a kdbg command, so ;-)
It seems that on process killing, some VACB may be deleted while
still mapped. With current reference counting, they will actually
not be deleted, but leaked, and an ASSERT will be triggered.
CORE-14578
