Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>
Newsgroups: comp.os.vms
Subject: Re: RX2800 sporadic disk I/O slowdowns
Date: Mon, 21 Oct 2024 12:44:47 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 55
Message-ID: <vf5ibv$uet0$5@dont-email.me>
References: <veu99d$3derp$1@dont-email.me> <veumb8$3gbt8$1@dont-email.me> <vf1ku6$3vhv$1@dont-email.me> <vf1lvv$3s2a$1@dont-email.me> <vf1m6n$444r$2@dont-email.me> <vf1mi6$3s2a$2@dont-email.me> <vf1nhv$444r$8@dont-email.me> <vf1nof$3s2a$3@dont-email.me> <vf1uo4$8qpm$2@dont-email.me> <vf2vsv$dvmh$1@dont-email.me> <vf3rvn$itru$1@dont-email.me> <vf3sbs$iugp$1@dont-email.me> <vf3tdg$itru$10@dont-email.me> <vf42hq$k0cc$1@dont-email.me> <vf45v3$kfm0$1@dont-email.me> <vf46bu$k0cc$2@dont-email.me> <vf477e$kfm0$4@dont-email.me> <vf47f9$k0cc$3@dont-email.me> <vf49n0$kvdg$1@dont-email.me> <vf4a2i$k0cb$1@dont-email.me> <vf4aoa$kvdg$8@dont-email.me> <vf4aum$k0cc$4@dont-email.me> <vf4hnr$pqrl$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 21 Oct 2024 14:44:48 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="40be50adf0b933f0d188c988be3c8358";
	logging-data="998304"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18sBMb2akBz62G46F34uBOU8qU5KJDmzNc="
User-Agent: slrn/0.9.8.1 (VMS/Multinet)
Cancel-Lock: sha1:5jCNq1GUmWtqwVsN0OTph5ZFZwc=
Bytes: 3801

On 2024-10-20, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Sun, 20 Oct 2024 21:32:05 -0400, Arne Vajh�j wrote:
>
>> On 10/20/2024 9:28 PM, Lawrence D'Oliveiro wrote:
>>> On Sun, 20 Oct 2024 21:17:06 -0400, Arne Vajh�j wrote:
>>>> On 10/20/2024 9:10 PM, Lawrence D'Oliveiro wrote:
>>>>> On Sun, 20 Oct 2024 20:32:41 -0400, Arne Vajh�j wrote:
>>>>>> On 10/20/2024 8:28 PM, Lawrence D'Oliveiro wrote:
>>>>>>> Transaction resilience is a standard thing with databases (and
>>>>>>> journalling filesystems) going back decades.
>>>>>>
>>>>>> Yes.
>>>>>>
>>>>>> But they can't do miracles.
>>>>>
>>>>> They can ensure, to a high degree of confidence, that the on-disk
>>>>> structure is consistent. That is to say, each transaction is either
>>>>> recorded as completed or not recorded at all, nothing in-between.
>>>>
>>>> Only if it can rely on a successful write not being lost.
>>> 
>>> In other words, that the disk controller is not lying to you when it says
>>> a write has completed?
>> 
>> Just that is is not lying when it says that it got it.
>
> That?s not what it is saying. It is saying ?write completed?.
>
>> A system crash and restart will blank RAM and wipe out all OS
>> and filesystem caches - it will not impact the cache in the
>> RAID controller.
>
> You hope.
>
> You really are a believer in miracles, aren?t you?

No, he isn't. He does understand however that the stored data will
be written to disk when power is restored and then any transaction
or other recovery process can proceed from there.

In addition, for data which is that important, you can run a fully
shared cluster setup across multiple sites so that the loss of a server
at one site does not really impact ongoing operations across the
system as a whole.

At this point Lawrence, I can't tell if you are just a troll who is
just trying to provoke people or if you really believe what you are
saying because you do not have a detailed understanding of how this
stuff works.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.