Hi guys,
the 0.42-WIP version of DOSLFN provided by Jason Hood will hopefully resolve
the filesystem corruption bug that was discussed earlier on the mailing list.
How does it do that? I had assumed that there was a kernel problem,
but it also is plausible that DOSLFN manipulates directors cluster
and sector data directly, because the kernel would not do LFN itself,
so the corruption was some sort of caching or buffers conflict? So
is the fix cache-related, kernel-related, or DOSLFN-itself-related?
Apparently, the fix was to have DOSLFN perform a "drive reset". While
the corruption problem no longer seems to appear, I do not know if this
actually “fixed” the problem itself. Or, if it just makes an underlying
problem (maybe in the kernel) not occur.
While I think it is very imported that this fix prevents filesystem
from getting corrupted, I agree with you that further investigation
should be made to ensure that there is not a serious bug elsewhere that
this fix is covering over.
I also think it's a kernel bug.
In doslfn.asm, a call to "install_long_filename" or
"install_long_filename_noflagtest" was preceded by a call to "ResetDrv"
in "lfn_mkdir", "lfn_move". The patch added this call in "lfn_creat",
too. There's still no such call in "Tunnel_Save2", though. In
"lfn_mkdir", there's a comment above the call to "ResetDrv" which, in
English, says "should be appended to cache (here not yet)" so, yes, it's
definitely cache-related.
The "ResetDrv" procedure can be disabled (patched with an early RET) with
the "/i-" option. The default is enabled.
That's what I could find out by comparing "doslfn.asm" of the DOSLFN
0.41f and 0.42-wip sources. But what cache is the comment about: A)
DOSLFN's own caches, B) DOS's internal cache or C) a disk cache (SmartDrv
etc.)?
A) is impossible as DOSLFN's sector caches are currently disabled, see
the comment "FastOpen is now disabled by default, since it doesn't
recognise disc changes and doesn't seem to impact performance (at least
with modern DOS)" and parts (structures "TDI", "TSC" and "TFO") disabled
with "IF [USEFASTOPEN|0] [...] ENDIF".
C) is unlikely because such disk caches should work transparently; also,
it's easy to test: if you don't load a disk cache, the problem should go
away; and there's the comment "sector data is held in cache because
MS-DOS doesn't cache anything, even when SmartDrv is loaded, when direct
disc access is detected" (which was written when the sector caches were
enabled by default).
What remains is B) which suggests that FreeDOS kernel's own sector cache
is doing something wrong. Resetting the drive (INT 21h, AH=0Dh) flushes
them out which makes the problem disappear.
Joe
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
