From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6471EC433EF for ; Tue, 31 May 2022 20:22:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237362AbiEaUWR (ORCPT ); Tue, 31 May 2022 16:22:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39160 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237041AbiEaUWQ (ORCPT ); Tue, 31 May 2022 16:22:16 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 93E1A2F009 for ; Tue, 31 May 2022 13:22:15 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 28424612A5 for ; Tue, 31 May 2022 20:22:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 09533C385A9; Tue, 31 May 2022 20:22:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1654028534; bh=roWsGZM+BasLwPWWs5v+eZz6hj4TQPf0LJiqGnd8sgc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=VCZRR7wNdE8pggEUnDOpECi6h+8bPxPPrPZlyuBZBtHhrw1okmGOOOMLKiDeZjqw9 BwoEQj97Ox7+AfVo0EMKu70/A+ZBOl6C9H6+f/DmrGv0suEG2t3LwVbK8vk8Kun0l3 pV+QUHPaoowyCwHVeKZ9+knKG3uVzQQzwRJvB4/GhLBdbYDOb0jiF5EurjbNXVu6dx 7kwS7kkv/SuPWugQHuseQnFgR3SwSeVnIuzoxmsB0rv5LI8SUPRUjgpcQp+YPfO9wD uoemRyv7rVMUpxP+lDgG4rzrVM99dwYyFSKCAPGKcL0PIdkoKV7OiQoOoQveXSUEnY PKrFWuM4EGGCA== Date: Tue, 31 May 2022 14:22:11 -0600 From: Keith Busch To: Eric Wheeler Cc: Adriano Silva , Christoph Hellwig , Bcache Linux , Matthias Ferdinand , Coly Li Subject: Re: [RFC] Add sysctl option to drop disk flushes in bcache? (was: Bcache in writes direct with fsync) Message-ID: References: <5486e421-b8d0-3063-4cb9-84e69c41b7a3@ewheeler.net> <7759781b-dac-7f84-ff42-86f4b1983ca1@ewheeler.net> <24456292.2324073.1653742646974@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-bcache@vger.kernel.org On Tue, May 31, 2022 at 12:42:49PM -0700, Eric Wheeler wrote: > On Sat, 28 May 2022, Keith Busch wrote: > > On Sat, May 28, 2022 at 12:57:26PM +0000, Adriano Silva wrote: > > > 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? > > > > The sysfs "write_cache" attribute just controls what the kernel does. It > > doesn't change any hardware settings. > > > > In "write back" mode, a sync write will have FUA set, which will generally be > > slower than a write without FUA. In "write through" mode, the kernel doesn't > > set FUA so the data may not be durable after the completion if the controller > > is using a volatile write cache. > > Something seems wrong here: Typically on a RAID controller LUN > configuration "writeback" means that the non-volatile cache is active so > "write back caching" is enabled. > > According to https://www.kernel.org/doc/Documentation/block/queue-sysfs.txt: > > "When read, this file will display whether the device has write > back caching enabled or not. It will return "write back" for the former > case, and "write through" for the latter." > > If my text mailer would underline then I would underline this from the > documentation: "whether the device has write back caching enabled or not" Maybe this is confusing because we let the user change the kernel's behavior regardless of how the storage device is configured? > Is there a good explanation for why the kernel setting is exactly > _opposite_ of the controller setting? By default, the drivers should have the correct setting reported for their devices, not the opposite. The user can override the sysfs attribute to the opposite setting though, so it's not necessarily an accurate report of what the device has actually enabled.