delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/01/07/08:56:03

Date: Tue, 7 Jan 1997 15:41:28 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Ronen Friedman <ronen AT Friendly DOT co DOT il>
cc: djgpp AT delorie DOT com
Subject: Re: DOS write buffers & DJGPP?
In-Reply-To: <199701070948.LAA00149@castle.trendline.co.il>
Message-ID: <Pine.SUN.3.91.970107153355.27480C-100000@is>
MIME-Version: 1.0

On Tue, 7 Jan 1997, Ronen Friedman wrote:

> What I meant by the "controlling the behaviour" is what I said 
> earlier - using off-times (once every few seconds) to perform the
> actual writes.

A call to `fsync' should do that.  But note that if ``once every few
seconds'' isn't fast enough, and DOS buffers are still filled, DOS will
flush them when they are full, without waiting for your call to `fsync'. 
Because of this, I think that writing to a large RAM disk and copying it
to the flash memory (if at all needed) when you see fit is a better
option, since then you have complete control of the actual write to flash
memory. 

> I didn't know flush_disk_cache() interacts with the SmartDrv(), and 
> assumed it is DOS that is affected. Perhaps the doc's should elaborate 
> here?

The docs mentions a ``write-behind disk cache''.  I never imagined that 
somebody will think it is about anything but a disk cache (such as 
SmartDrv), since plain DOS doesn't include such a cache.  I will add some 
more words that will make it more clear.

> But the main question remains: suppose I disable the SmartDrv. Can I 
> force DOS to withhold writing onto the disk until an fsync()?

I don't think you can do that.  What else can DOS do when its buffers are 
full?

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019