delorie.com/archives/browse.cgi   search  
Mail Archives: opendos/1997/02/13/22:32:51

From: mharris AT blackwidow DOT saultc DOT on DOT ca
Date: Thu, 13 Feb 1997 21:52:15 -0500 (EST)
Reply-To: mharris AT blackwidow DOT saultc DOT on DOT ca
To: yeep <yeep AT xs4all DOT nl>
cc: "'OpenDOS newsgroup'" <opendos AT mail DOT tacoma DOT net>
Subject: Re: [opendos] Re: [opendos-developer] Caching
In-Reply-To: <199702131820.TAA16620@magigimmix.xs4all.nl>
Message-ID: <Pine.LNX.3.95.970213214537.1576F-100000@206.248.78.17>
Organization: Total disorganization.
MIME-Version: 1.0
Sender: owner-opendos AT mail DOT tacoma DOT net

On Thu, 13 Feb 1997, yeep wrote:

> > Nothing at all.  The code *should* be inside the device driver or
> > whatever just as you state, however I'm talking about removeable
> > disks that could be yanked out before someone unmounts them, thus
> > the cache software doesn't get a chance to unmount the drive.  I
> > guess the cache software is what should be responsible. In other
> > words, by using the current method of picking which drives get
> > cached, you could enable/disable caching on removable media as
> > you see fit.  I think that the default behavior of the disk cache
> > should be to not cache any removeable disks though.
> 
> I read something, I think it was the cacher supplied in OD, that when the
> prompt is back on the screen, the cache has been dumped.
> In linux this will be when the process ends I guess.
> In other words: You play a game from floppy (don't laugh! It's just an
> example) and you quit, after saving your hi-score ofcourse.
> The program ends, the cacher get's a signal from the shell(?) and dumps all
> delayed-write-stuff to the disk, then gives the user a prompt, which
> indicated that the floppy can be removed safely.
> This does not mean however that a floppy cacher is useful :-)

No, that is only useful if you remember to sync the drive, or
umount it before ripping out the disk.

Consider this.

$mount /dev/fd0 /a -t msdos
$cp txt/* /a/
A 3 second wait for a 1.3Mb transfer to floppy.
Now the drive light is off, and you pull the disk out (like you
would in DOS).  However, the command prompt *IS* back, and the
cache hasn't written the data to disk.  Kiss the disk goodbye.

Also, even if you could make the command prompt come back, this
would just delay the copy operation so that you'd have to wait
for it before doing anything else.  What? In a multitasking OS?
Heck, any commands that don't give me my prompt back get shoved
in the background, so that copy command becomes:

$cp txt/* /a/ &

And the prompt is back.

I'm going to scour the mount manpage again. I tried the following
"mount -o async", but it doesn't work.

TTYL

Mike A. Harris        |             http://blackwidow.saultc.on.ca/~mharris
Computer Consultant   |    My webpage has moved and my address has changed.
My dynamic address: http://blackwidow.saultc.on.ca/~mharris/ip-address.html
mailto:mharris AT blackwidow DOT saultc DOT on DOT ca

  Visit my homepage if you want your Dynamic IP address on your webpage.

- Raw text -


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