[Info-vax] Databases versus RMS

[David Froble]

Johnny Billquist wrote:
> On 2012-04-18 14:57, David Froble wrote:
>> Johnny Billquist wrote:
>>> On 2012-04-18 12:51, Dirk Munk wrote:
>>>> VAXman- @SendSpamHere.ORG wrote:
>>>>> In article<4f8dc739$0$1688$c3e8da3$50776f34 at news.astraweb.com>, JF
>>>>> Mezei<jfmezei.spamnot at vaxination.ca> writes:
>>>>>> {...snip...}
>>>>>>
>>>>>>> And, generaly speaking, Rdb is more "safe" then a plain RMS
>>>>>>> based "database".
>>>>>>
>>>>>> An RMS write tends to result in an immediate physical write to disk.
>>>>>> (unless hidden by a storage array which delays writes).
>>>>>
>>>>> That's not true!
>>>>>
>>>> Indeed it is not. Cobol for instance has the deferred write option.
>>>
>>> Even beyond any language issue, or RMS details, the OS can cache and
>>> defer actual writes to the disk without you ever knowing about it. Not
>>> to mention that disks also cache things...
>>>
>>> Johnny
>>>
>>
>> If Cobol is doing a deferred write, ie; don't write the buffer until
>> necessary, then that is NOT a "write to disk".
> 
> Right. And important to understand, as "RMS write" might mean different 
> things to different people.
> 
>> It's my understanding that VMS does a "write through cache", which would
>> result in a directive to the storage device to "write" the data. Now, if
>> you're using a storage device that doesn't do as it's told ....
> 
> Unfortunately I have forgotten (if I ever knew) how VMS caching works. 
> In RSX, writes can be deferred by the caching layer, which is located 
> beneath the QIO processing in the OS.
> So, even when you have done the actual QIO to write the disk block, it 
> might still not be written out to disk yet. It's basically a write back 
> cache.
> 
>  From a performance point of view, I'd be surprised in VMS could not 
> offer the same, but from a data safety point of view, write back is 
> preferable...
> 
>     Johnny
> 

The disk caching implemented on VMS back in V7.2 or 7.3 or thereabouts works very well. 
The write-through is a method to insure that data makes it to the disk, or at least the 
disk controller, without you waiting on a sync write to complete.  Once you've done your 
write, your operation is complete.  What the caching does is update the cached data, AND, 
initiates a write of the changed data to disk.  This, additional reads of the data can be 
satisfied from the cache, while data integrety is assured, well within reason, by the 
write through to disk.

In general disk activity might be 90% reads, and 10% writes.  In such a scenario, cached 
data is read much more quickly, and, for the writes, they go to disk as well as the cache, 
(actually, to the cache, and then to disk).  About as good as you can get, fast access 
from memory, and write through to disk for integrity.