Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: =?UTF-8?Q?Arne_Vajh=C3=B8j?= Newsgroups: comp.os.vms Subject: Re: RX2800 sporadic disk I/O slowdowns Date: Sun, 20 Oct 2024 19:08:41 -0400 Organization: A noiseless patient Spider Lines: 20 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Mon, 21 Oct 2024 01:08:42 +0200 (CEST) Injection-Info: dont-email.me; posting-host="e557ab2ded888c175ae698c2a2678a45"; logging-data="655756"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18oUryt5KMs0Gvkl4r1DdPodNJrJNmnlo8=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:1/92roK/K47KnRQgNMZpGOVrZzI= In-Reply-To: Content-Language: en-US Bytes: 2127 On 10/20/2024 5:41 PM, Lawrence D'Oliveiro wrote: > On Sun, 20 Oct 2024 17:23:08 -0400, Arne Vajhøj wrote: >> Loss of completed/committed data is the problem. > > The problem is not data loss, it is loss of data integrity. This is why we > have transactions in databases and filesystems: on a crash or loss of > power, we want transactions to be either completely lost or completely > saved, not in some in-between incomplete state. > > There is no caching disk controller that knows how to ensure this. Let me try again. DB write to plates & system crash => OK but slow DB write to OS cache & system crash => potential problem with transaction DB write to RAID controller with battery backup & system crash => OK and fast Arne