Re: RamFAST & GS/OS cache

[toddpw@cco.caltech.edu (Todd P. Whitesel)]

mattd@apple.com (Matt Deatherage) writes:

>Todd suggested that FSTs should read cache memory directly; this is a bad
>idea.  Dave is right on target -- if that happened, devices wouldn't have
>a way to detect media swaps and flush the cache, and you could get blocks
>belonging to a disk you ejected a while back.  Drivers can't notice disks
>are ejected until someone calls the driver and gives it code time -- right
>now, they get that on every read call and the driver manages the cache.

Matt, you are dismissing my idea based on an incorrect/incomplete analysis
of its consequences. Sound familiar from the MSDOS R/W thread on GEnie? I
hope so. Let's see if we can avoid that this time.

Your counter-argument assumes that the FST would treat its pointer into the
cache the way an application is _allowed_ to treat a handle. That can never
work, for exactly the reasons you stated. But there is no good reason why
that should be how the FST treats its pointer! If you instead require the
FST to get a new pointer from the driver every time it would normally read
the block, AND require the FST to discard the pointer (perhaps forcing an
extra get-pointer call to the driver) any time the cache contents could be
modified, then everything works because the FST only uses its pointer when
it is valid, and the driver is allowed the code time it needs to handle
volume changes. If the FST really wants a block to stick around across
other disk accesses, then it has two options: copy the block to a private
buffer, or add a "block lock" feature to the cache that disables flushing
of important blocks _unless_ the volume they are from is ejected.

This all assumes that the driver interface can be expanded to handle any
additional calls or parameters without serious difficulty. If that isn't
possible then we are pretty much sunk, but I believe the driver interface
is cool enough to handle it (I'd need to check tho).

Todd Whitesel
toddpw @ cco.caltech.edu