Hi, El dom, 3 ago 2025 a las 2:34, tom ehlert via Freedos-devel (< freedos-devel@lists.sourceforge.net>) escribió:
> > 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
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
