This bug is terrible to read about. I still can't believe that INT 25 and 26 were not going through the buffer cache.
Anything that blindly writes a sector before it reads it is broken, unless it's wiping something out. So you can assume that a read to a specific sector will always precede a write to it. - Reads through INT 25 can use cached data (dirty or not) directly. This makes sense for performance. If you modify a sector, especially a FAT sector, there is a good chance you are going to read it again soon. - Writes through INT 25 should invalidate any copy in the cache and be forced to disk. Somebody using INT 26 and not normal file I/O is probably expecting the write to make it to the media immediately. For performance on writes a non-dirty copy can be left in the buffer, and I think that is fine. The overhead of the cache management is tiny compared to the rest of the code paths and the time spent doing the I/O, even on FLASH based devices. And the concerns about saturating the buffer are unfounded, as most DOS systems don't have a lot of buffer space so it's always getting saturated and turned over.
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
