| Deutsch English Français Italiano |
|
<vf47f9$k0cc$3@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: =?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> Newsgroups: comp.os.vms Subject: Re: RX2800 sporadic disk I/O slowdowns Date: Sun, 20 Oct 2024 20:32:41 -0400 Organization: A noiseless patient Spider Lines: 38 Message-ID: <vf47f9$k0cc$3@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> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Mon, 21 Oct 2024 02:32:42 +0200 (CEST) Injection-Info: dont-email.me; posting-host="e557ab2ded888c175ae698c2a2678a45"; logging-data="655756"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19j6N4BGXxDFDmJQ+Qz2PyJ7ZUJeSyab10=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:ZLvhJufTNddXgZznnhlFWwon7YY= In-Reply-To: <vf477e$kfm0$4@dont-email.me> Content-Language: en-US Bytes: 2738 On 10/20/2024 8:28 PM, Lawrence D'Oliveiro wrote: > On Sun, 20 Oct 2024 20:13:50 -0400, Arne Vajhøj wrote: >> On 10/20/2024 8:06 PM, Lawrence D'Oliveiro wrote: >>> On Sun, 20 Oct 2024 19:08:41 -0400, Arne Vajhøj wrote: >>>> Let me try again. >>>> >>>> DB write to plates & system crash => OK but slow >>> >>> The DB knows how to make this fast. Remember its cache is faster than >>> any disk controller. >> >> This is where the DB is writing to plates. >> >> You can add a fourth scenario: >> >> DB write to DB cache & system crash => guaranteed problem with >> transaction > > Transaction resilience is a standard thing with databases (and journalling > filesystems) going back decades. Yes. But they can't do miracles. To be sure to come up ok after a system crash it is either write to plates or write to a cache that will survive the system crash (raid controller cache with battery backup). > Some DBMSes don’t even want to work through filesystems, they would rather > manage the raw storage themselves. This is why POSIX async I/O exists > <https://manpages.debian.org/7/aio.7.en.html>. Yes. That is to avoid any dangerous OS/filesystem cache (and possible for better performance). Arne