[Info-vax] Databases versus RMS
Johnny Billquist
bqt at softjar.se
Wed Apr 18 13:48:50 EDT 2012
On 2012-04-18 18:47, David Froble wrote:
> 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.
Whoa! What you just described in the latter parts are a write-back cache.
If the write completes when the data have entered the cache subsystem,
and the cache subsystem then initiates a write to save the data out to
disk, then you have a write-back.
In a write-through, your write operation does not complete until the
data has actually been written out. The cache will be updated by the
write, but the cache is not in control of the write.
In the write-back cache, you might think the data have been written,
since your operation have completed, but in reality that is not the
case, since the cache subsystem might not have completed the write yet.
It also means that if you get a power failure (for example) between your
write completing, and the cache subsystem even starting the operation,
means that your program though the data had been written, but in reality
it was lost.
> 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.
There is a big and important difference between "go to disk as well as
the cache" and "to the cache, and then to disk".
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
More information about the Info-vax
mailing list