Until now, our support for dirty volumes was totally broken
to a point where, on FAT32 volume, the dirty couldn't even
be written nor read from the disk.
This commit totally rewrites its handling, for both FAT16 and FAT32
so that it's now fully functionnal. Furthermore, it also gets
totally compatible with our vfatlib, and thus, autochk.
Now, on mount, FastFAT will check if the volume is dirty or not, and
autochk will be able to ask for a repair if dirty. vfatlib will
repair the volume and remove the dirty bit. So that, on next
reboot, the volume will be mounted clean.
As a reminder, the dirty bit is set immediately after mounting
the volume, so that, if you crash or have a powercut, autochk
will always attempt to repair your volume (with more or less,
that's FAT!).
If you want to experience without breaking your FAT volume,
just boot, open a cmd prompt and type: fsutil dirty set c:
and reboot!
CORE-13758
CORE-13760
CORE-13759
This is a hack, and totally not the default behavior.
But it will allow autochk locking the boot volume in
order to verify it on boot, in case it would have
been improperly dismounted.
CORE-13759
This avoids initializing cache directly on directory
open/create.
The advantage is we reduce the load on cache manager
and on memory manager by avoiding creating everytime
a stream file object, and initializing cache for it.
This will avoid initializing cache for started
applications 'current directory' which is just opened
for having a valid handle but no read/write is performed
in it, by default.
This is a step forward for autochk.
CORE-14629
Before performing a read operation, FastFAT driver will
attempt to compute whether it would run out of stack
during the operation. If so, instead of attempting the
operation in the current thread, it will post the read
request to the overflow thread.
This should help with the regressions brought in by
94ead99e0c.
CORE-14601
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
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
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
- Allow the driver to be unloaded, as on Windows.
- Use a static fast IO dispatch table, instead of allocating one and
risking any potential memory allocation failure.
- Update the file header.
This makes the function return the error instead of continuing and
performing use-after-frees operations.
This is likely to be a forgotten return!
CID 1434254, 1434268
is set before locking is actually attempted for Cc worker thread (lazy write/read ahead).
So in case locking fails, the top level IRP is set and never unset, and latter
call will hit the assert where it expects the top level IRP to be NULL.
Should be reported upstream (tm).
CORE-14315
