On Aug 3, 2025, at 2:54 PM, Aitor Santamaría via Freedos-devel <freedos-devel@lists.sourceforge.net> wrote:
Hi, > I agree that you would get better performance when
> raw writes just UPDATE buffer contents instead of
> triggering full cache INVALIDATION.
full cache INVALIDATION is only needed because the BUFFERS cache
might have stale data that are not yet on disk.
It's a brute force clutch, not a real solution.
The solution should be to use the same BUFFERS cache for both
internal mk_dir etc. operations, and external lfn_mkdir operations.
> I suggest that raw writes should not FILL buffers,
> but only UPDATE buffers for those sectors which
> already happen to be in the buffers.
This happens automagically in the current context as DOSLFN newer
writes sector data, but always read/modify/writes data.
So data written to are already in the cache, read microseconds before.
i.e. treat external int2526_handler reads/writes like internal mk_dir
reads/writes, while observing the int21_fat32 (dir, fat, data)
destination. basically cache dir and fat calls, don't cache data or unknown.
I think it would be interesting to know if/how MS-DOS kernel handles this: if the same bug appears using MS-DOS or MS-DOS is able to handle this properly (preferably MS-DOS 6.2 or under). (I can't check it myself, I am currently away for holidays). As if it doesn't show the bug, would be a clear indication that it is probably handled this way by Microsoft too.
Aitor
Other than verifying the “bug” existed, I personally have not performed any sort of analysis on it. But, this was all discussed on the list earlier.
The bug involved the usage of the FreeDOS kernel, DOSLFN and FDNPKG. It only appeared when all three were in play and when files were being installed that contained rare but legal characters in their file name. These file names were 8.3 compliant and did not need LFN support.
Changing any of the three programs involved resulted in the bug not appearing and the filesystem not being corrupted. So using the MSDOS kernel with DOSLFN and FDNPKG was fine. But, also using the FreeDOS kernel with DOSLFN and FDINST was fine.
The bug could be reliably produced when installing those specific packages and occurred at the same point in repeated tests.
Again, changing any one of the programs involved resulted in the bug disappearing. Changing other items, like the memory manager, its setting, boot configuration, other drivers and so on had no effect on this bug.
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
|
