Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Stephen Fuld <sfuld@alumni.cmu.edu.invalid>
Newsgroups: comp.arch
Subject: Re: Is Parallel Programming Hard, And, If So, What Can You Do About
 It?
Date: Tue, 20 May 2025 20:58:53 -0700
Organization: A noiseless patient Spider
Lines: 30
Message-ID: <100jj1u$2fpjs$2@dont-email.me>
References: <vvnds6$3gism$1@dont-email.me>
 <edb59b7854474033c748f0fd668badaa@www.novabbs.org>
 <w32UP.481123$C51b.217868@fx17.iad> <vvqdas$g9oh$1@dont-email.me>
 <vvrcs9$msmc$2@dont-email.me>
 <0ec5d195f4732e6c92da77b7e2fa986d@www.novabbs.org>
 <vvribg$npn4$1@dont-email.me> <vvs343$ulkk$1@dont-email.me>
 <vvtt4d$1b8s7$4@dont-email.me> <2025May13.094035@mips.complang.tuwien.ac.at>
 <vvuuua$1mt7m$1@dont-email.me> <vvvons$3uvs3$2@dont-email.me>
 <1000nfp$2440u$1@dont-email.me> <1000pae$3uvs3$3@dont-email.me>
 <100bdhq$lhdb$3@dont-email.me>
 <91c8a31fc5d04a1fadf210b2dd6d4875@www.novabbs.org>
 <100e0it$19264$1@dont-email.me>
 <fa7e33d953bc6f545387d862e19c2bd2@www.novabbs.org>
 <100gipr$1sbnn$10@dont-email.me> <100h3jm$23ehu$1@dont-email.me>
 <jwv7c2bjqcx.fsf-monnier+comp.arch@gnu.org> <100j6pq$2fqhj$9@dont-email.me>
 <100j9e7$2gdpc$1@dont-email.me> <100jib4$2lgt3$6@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 21 May 2025 05:58:54 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3e19388d1f94c303016529f9574bae0a";
	logging-data="2614908"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18V7kgrRu3zIs4du+wAaTLv4q96ew1jiI0="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:I0OVzP/xF2elNU4rXaXAXoLw+40=
Content-Language: en-US
In-Reply-To: <100jib4$2lgt3$6@dont-email.me>
Bytes: 3233

On 5/20/2025 8:46 PM, Lawrence D'Oliveiro wrote:
> On Tue, 20 May 2025 20:08:28 -0500, BGB wrote:
> 
>> On 5/20/2025 7:29 PM, Lawrence D'Oliveiro wrote:
>>
>>> If it were just I/O buffers for operations in progress, that would be
>>> fine. The problem is when it keeps data around instead of immediately
>>> writing it out, and what’s worse, lies about it, so it tells the OS
>>> that the write has completed when it hasn’t.
>>
>> Note that (with SATA and similar) the OS can request that the drive
>> flush its caches, and (in theory) drive should not respond to more
>> requests until everything has been fully written back to disk.
> 
> I mentioned elsewhere that a special function was added that was supposed
> to mean “really flush your caches dammit”.
> 
> But there is still no way to tell that the drive really does what you
> demand that it do, and isn’t still lying about it ...

Sure there is.  Just do a small write to a random location and time it. 
repeat several times to assure consistent results.

Besides, if a disk vendor was foolish enough to not follow the spec and 
not document that fact, customers would soon find out and that would 
ruin that vendor's reputation.  They wouldn't risk it.

-- 
  - Stephen Fuld
(e-mail address disguised to prevent spam)