Hallo Herr Eric Auer via Freedos-devel, am Dienstag, 5. August 2025 um 02:00 schrieben Sie:
> Hi Tom, >> 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. > Scary. How about triggering a kernel panic if a dirty > buffer is detected to contain one of the sectors which > was about to be written by int26 or int 21.7305? After thinking about this for while, new insights. You don't even need dirty buffers to cause this problem (and I don't think the kernel has any dirty buffers that are not partly written file *data* sectors). Consider this scenario (as it probably happens in between FDNPKG,DOSLFN, kernel) someone writes normal data through the kernel. The kernel has to allocate a new cluster, read the FAT table into the cache, modifies it and writes back (but leaves it in the cache). now DOSLFN wants to create a new directory entry, must allocate a new cluster for the directory entry, reads the FAT from disk, modifies the FAT sector, and writes it to the disk. all fine so far, but the kernel still has the *unmodified* sector in it's cache. now when the kernel has to allocate the next cluster, it finds the *stale* copy of the FAT in its cache, re-allocates the same cluster for it's own use, and writes the modified FAT sector to the disk. so the same cluster is used once by DOSLFN, once by the kernel. DOOM. No dirty buffers involved. I recommend the solution for INT25/26 to look at the top of the BUFFERS cache for the same view of the (cached) disk as the kernel. IMO this should solve the trouble. Tom _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
