Re: [RFC] Add sysctl option to drop disk flushes in bcache? (was: Bcache in writes direct with fsync)

From: Adriano Silva <adriano_da_silva@yahoo.com.br>
To: Christoph Hellwig <hch@infradead.org>,
	Bcache Linux <linux-bcache@vger.kernel.org>,
	Matthias Ferdinand <bcache@mfedv.net>, Coly Li <colyli@suse.de>,
	Eric Wheeler <bcache@lists.ewheeler.net>,
	Keith Busch <kbusch@kernel.org>
Subject: Re: [RFC] Add sysctl option to drop disk flushes in bcache? (was: Bcache in writes direct with fsync)
Date: Sat, 28 May 2022 12:57:26 +0000 (UTC)	[thread overview]
Message-ID: <24456292.2324073.1653742646974@mail.yahoo.com> (raw)
In-Reply-To: <YpGsKDQ1aAzXfyWl@infradead.org>

Dear Christoph,

> Once you do that, the block layer ignores all flushes and FUA bits, so
> yes it is going to be a lot faster.  But also completely unsafe because
> it does not provide any data durability guarantees.

Sorry, but wouldn't it be the other way around? Or did I really not understand your answer?

Sorry, I don't know anything about kernel code, but wouldn't it be the other way around?

It's just that, I may not be understanding. And it's likely that I'm not, because you understand more about this, I'm new to this subject. I know very little about it, or almost nothing.

But it's just that I've read the opposite about it.

 Isn't "write through" to provide more secure writes?

I also see that "write back" would be meant to be faster. No?

But I understand that when I do a write with direct ioping (-D) and with forced sync (-Y), then an enterprise NVME device with PLP (Power Loss Protection) like mine here should perform very well because in theory, the messages are sent to the hardware by the OS with an instruction for the Hardware to ignore the cache (correct?), but the NVME device will still put it in its local cache and give an immediate response to the OS saying that the data has been written, because he knows his local cache is a safe place for this (in theory).

On the other hand, answering why writing is slow when "write back" is activated is intriguing. Could it be the software logic stack involved to do the Write Back? I don't know.

Em sábado, 28 de maio de 2022 01:59:30 BRT, Christoph Hellwig <hch@infradead.org> escreveu: 

On Fri, May 27, 2022 at 06:52:22PM -0700, Eric Wheeler wrote:

> Adriano who started this thread (cc'ed) reported that setting 
> queue/write_cache to "write back" provides much higher latency on his NVMe 
> than "write through"; I tested a system here and found the same thing.
>
> [...]
>
> Is this expected?

Once you do that, the block layer ignores all flushes and FUA bits, so
yes it is going to be a lot faster.  But also completely unsafe because
it does not provide any data durability guarantees.