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 DAB96C433EF for ; Wed, 25 May 2022 05:20:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230475AbiEYFUZ (ORCPT ); Wed, 25 May 2022 01:20:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42260 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236574AbiEYFUY (ORCPT ); Wed, 25 May 2022 01:20:24 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B85471DA64; Tue, 24 May 2022 22:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Transfer-Encoding :Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=YbBZJecasFJChD0Qx766ygv34+7CE3nsA11f44Yl+UI=; b=OPYvc+r5yRmAXpLvPMiOYs/E8G mcFb7ZPfMh5tPcXBZXIy2Tw//q2WNL/BnmHUJeRnqvYIGqlQGhaeJBNUvzVR/qcUmvtE3GquNOu7J qE/5nd70uqkfnkgb3+MI0cZxe6qRi0fLP9nolxFOeNLS9TVZybFjampx5UxLYGc1pnC4G8h0jo1lS wglmXsdJtVM625U+esHSCVFJ5QXyx8MzYdwFJAlBfQo9xzN6zCaHmAl1JyqVdjW5UyDgKuC7imgeD f5XXJjZxFVhFBjytgKzA/v11J2EQKlIxiFY/AVDdmrNLVHqCxpfaK3YS1OdKMSv0quwNNSRWkcIDC en+FWfhA==; Received: from hch by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1ntjRQ-009yDS-6p; Wed, 25 May 2022 05:20:16 +0000 Date: Tue, 24 May 2022 22:20:16 -0700 From: Christoph Hellwig To: Eric Wheeler Cc: Keith Busch , Christoph Hellwig , Coly Li , Adriano Silva , Bcache Linux , Matthias Ferdinand , linux-block@vger.kernel.org Subject: Re: [RFC] Add sysctl option to drop disk flushes in bcache? (was: Bcache in writes direct with fsync) Message-ID: References: <958894243.922478.1652201375900.ref@mail.yahoo.com> <958894243.922478.1652201375900@mail.yahoo.com> <9d59af25-d648-4777-a5c0-c38c246a9610@ewheeler.net> <27ef674d-67e-5739-d5d8-f4aa2887e9c2@ewheeler.net> <5486e421-b8d0-3063-4cb9-84e69c41b7a3@ewheeler.net> <7759781b-dac-7f84-ff42-86f4b1983ca1@ewheeler.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7759781b-dac-7f84-ff42-86f4b1983ca1@ewheeler.net> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Precedence: bulk List-ID: X-Mailing-List: linux-bcache@vger.kernel.org On Tue, May 24, 2022 at 02:34:23PM -0700, Eric Wheeler wrote: > Is this flag influced at all when /sys/block/sdX/queue/scheduler is set > to "none", or does the write_cache flag operate independently of the > selected scheduler? This in completely independent from sthe scheduler. > Does the block layer stop sending flushes at the first device in the stack > that is set to "write back"? For example, if a device mapper target is > writeback will it strip flushes on the way to the backing device? This is up to the stacking driver. dm and tend to pass through flushes where needed. > This confirms what I have suspected all along: We have an LSI MegaRAID > SAS-3516 where the write policy is "write back" in the LUN, but the cache > is flagged in Linux as write-through: > > ]# cat /sys/block/sdb/queue/write_cache > write through > > I guess this is the correct place to adjust that behavior! MegaRAID has had all kinds of unsafe policies in the past unfortunately. I'm not even sure all of them could pass through flushes properly if we asked them to :(