Depends if the app is using direct io To: "Technical discussion and questions for FreeDOS developers." ;Cc: tom ehlert ;Subject: [Freedos-devel] DOSLFN bugfix explanations and ideas - was: FreeDOS Interim Build T2508;13:34, August 15, 2025, "tom ehlert via Freedos-devel" : I'm pretty certain that
> I'm pretty certain that most DOS installations use a minimal setting for
> the BUFFERS= directive in config.sys. I've never seen anything over 30.
As a little known fact:
for FreeDOS, "BUFFERS=10" is implemented as "at least 10, or whatever fits
into HIGH memory"
"BUFFERS=-10" means "exact
PS: rwblock already calls DeleteBlockInBufferCache (NOT searchblock)
in selected situations before calling dskxfer for the actual I/O.
Maybe the problem simply is that int21_fat32 and int2526_handler
should both use rwblock instead of the more low level dskxfer?
All other uses of dskxfer look
Hi Michael,
Cache pollution is not an issue when your cache is already tiny - it's
always being flooded. The BUFFERS cache primary exists to pick up the easy
case of sectors being read or modified close in time, like during a FAT
update...
Even then, it is much better to only invalidate the
I'm pretty certain that most DOS installations use a minimal setting for
the BUFFERS= directive in config.sys. I've never seen anything over 30.
Cache pollution is not an issue when your cache is already tiny - it's
always being flooded. The BUFFERS cache primary exists to pick up the easy
case
Hi Tom, Bernd, Michael et al,
I think int 25/26 etc. MUST indeed ensure BUFFERS cache CONSISTENCY,
but should NOT trigger ALLOCATION of cache items. See my explanations.
Consider this scenario (as it probably happens in between FDNPKG,DOSLFN, kernel)
someone writes normal data through the ke
