Commit 04030b45 authored by Robert Sprowson's avatar Robert Sprowson

Docs update

Having disassembled various old copies of FileCore, make a note of the most likely reason it declares with fsinfo_dontuseload to maximise the use of background transfer buffers.
Not tagged.
parent 45dadad2
......@@ -60,7 +60,7 @@ When idle FileCore will look to see if any more background work could be
started. If writes are possible the first buffer (attached to the Fcb) will
be picked and using its BufFileOff this is mapped to a fragment. More buffers
will be considered (using SkipWriteBehind and BackwardsSkipWriteBehind) to
see how many buffers cover the corresponding fragment. These are then inserted
see how many buffer s cover the corresponding fragment. These are then inserted
in one go onto a scatter list and consumed.
Later, the above steps will repeat. Due to the way the buffers are attached
to the Fcb this results in writing backwards through the file as it happens.
......@@ -96,3 +96,16 @@ in sync, the buffer address can be recreated by just adding RamAdjust.
DiscAdjust works the same, only it's a disc address rather than RAM.
I'm thinking that DiscAdjust must be always sector aligned. If
this assumption breaks I'll have fun.
OS_File Load
------------
At least as far back as FileCore 2.41, and throughout all CVS history, FileCore
has registered with FileSwitch with bit 20 (fsinfo_dontuseload) of the FS
info word set.
This is rationalised as being so that the GetBytes entry gets used in the
hope that some of the request can be met from the read ahead cache.
The code to handle OS_File 255 (DoOsFileLoad in FileCore45.s) bypasses the
read ahead cache, using IndDiscOp directly, but the function is never called.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment