Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp293076ybl; Wed, 4 Dec 2019 02:56:29 -0800 (PST) X-Google-Smtp-Source: APXvYqwfW11tNTyBc3GjzUQXeOGCBjTyt8Kx9wGdphjxHtys75L0XxC3wLQNuCe7e3w3AzzY9DzS X-Received: by 2002:a54:4407:: with SMTP id k7mr2088866oiw.56.1575456989486; Wed, 04 Dec 2019 02:56:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575456989; cv=none; d=google.com; s=arc-20160816; b=NjVhE+zJB01vk4j/5fYhhpE6f6dumL6hEGtvRhJ6HU56ubKbNKXWYMKK4fHYTunF+F uYK7BQ35yofYOfDml8rvk75zYcR4ivLgR01BrPW9cI45EOe76bNeIa7dmn43YZ5fFdYt 60nKZtMkc+o6qidD4K1OIDDSXWTzoCvviVghBmPt/YKsaT6BRT+h84VFotBoOaYxS/3i FNd2ZoXkp/QeNeUIiQgxELZ8aY+XrozB6JTwsopm6Khg07u+1eoFROqzQ7CLi9wZVC0D YK5Y03g4jO4kV6u1QNRSHwcm86oJNSL8PmXuizAGozj/eIC3rlsKN7kNy4a1rGW/1EDC XUmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:references:cc:to:from:subject; bh=1PLMcfs/rnkGkb4R+FfHPl9So4mBul93SrLW5z9xnuE=; b=esDkDi3bJMJs+SEtsHhr3vZOZX527Osvuum+y0mUDJNKNhj6RKuIMDF3ADu911q0s0 FIKxW/pmV/ysSTBxDn/IPn0YDmn8YydIMYmBZdo0OaPt9jWXeZg0jtCTcDfzc7thq66W Axxm53NJwTDbZumW3JN7ZTpHbPFJx2IcD7zC3n9ODmqjaoEFnCobPmgM1uwPxOTvGYnM 4LWwzO9j0GSZS+v8H1cwe30H6spFnlZA3ytZ+eei5AUtBUjSVEp5rPjcT7rUe3onFECL JJ7PnGaNqPX/WFEgIZAvIg36Tvmf3bct7oABm4yWFL4BA2FmlACno4AowGsnW7K2hW9H csaw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b2si2997631oib.272.2019.12.04.02.56.17; Wed, 04 Dec 2019 02:56:29 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727601AbfLDKzW (ORCPT + 99 others); Wed, 4 Dec 2019 05:55:22 -0500 Received: from mx2.suse.de ([195.135.220.15]:52978 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727445AbfLDKzW (ORCPT ); Wed, 4 Dec 2019 05:55:22 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 50AA6B280; Wed, 4 Dec 2019 10:55:20 +0000 (UTC) Subject: Re: [PATCH] bcache: add REQ_FUA to avoid data lost in writeback mode From: Coly Li To: Eric Wheeler Cc: kungf , kent.overstreet@gmail.com, linux-bcache@vger.kernel.org, linux-kernel@vger.kernel.org References: <20191202102409.3980-1-wings.wyang@gmail.com> <785fe04f-f841-3083-66db-53fab7bc0577@suse.de> <1a728329-1b12-0ebf-21a4-058ef6f65ead@suse.de> Organization: SUSE Labs Message-ID: <2d085823-57ac-dba9-6d2e-1cf01c949875@suse.de> Date: Wed, 4 Dec 2019 18:55:08 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <1a728329-1b12-0ebf-21a4-058ef6f65ead@suse.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019/12/3 10:21 下午, Coly Li wrote: > On 2019/12/3 3:34 上午, Eric Wheeler wrote: >> On Mon, 2 Dec 2019, Coly Li wrote: >>> On 2019/12/2 6:24 下午, kungf wrote: >>>> data may lost when in the follow scene of writeback mode: >>>> 1. client write data1 to bcache >>>> 2. client fdatasync >>>> 3. bcache flush cache set and backing device >>>> if now data1 was not writed back to backing, it was only guaranteed safe in cache. >>>> 4.then cache writeback data1 to backing with only REQ_OP_WRITE >>>> So data1 was not guaranteed in non-volatile storage, it may lost if power interruption  >>>> >>> >>> Hi, >>> >>> Do you encounter such problem in real work load ? With bcache journal, I >>> don't see the possibility of data lost with your description. >>> >>> Correct me if I am wrong. >>> >>> Coly Li >> >> If this does become necessary, then we should have a sysfs or superblock >> flag to disable FUA for those with RAID BBUs. > > Hi Eric, > > I doubt it is necessary to add FUA tag for all writeback bios, it is > unnecessary. If power failure happens after dirty data written to > backing device and the bkey turns into clean, a following read request > will go to cache device because the LBA can be indexed no matter it is > dirty or clean. Unless the bkey is invalidated from the B+tree, read > will always go to cache device firstly in writeback mode. If a power > failure happens before the cached bkey turns from dirty to clean, just > an extra writeback bio flushed from cache device to backing device with > identical data. Comparing the FUA tag for all writeback bios (it will be > really slow), the extra writeback IOs after a power failure is more > acceptable to me. Hi Eric, I come to realize what the problem is. Yes there is potential possibility.With FUA the writeback performance will be very low, it is quite tricky.... Coly Li