From patchwork Wed Sep 20 16:07:35 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kent Overstreet X-Patchwork-Id: 9961787 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 4B16C60208 for ; Wed, 20 Sep 2017 16:07:52 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3C52E2913D for ; Wed, 20 Sep 2017 16:07:52 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 30FF029140; Wed, 20 Sep 2017 16:07:52 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.5 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BED2D2913D for ; Wed, 20 Sep 2017 16:07:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751618AbdITQHu (ORCPT ); Wed, 20 Sep 2017 12:07:50 -0400 Received: from mail-wr0-f195.google.com ([209.85.128.195]:34774 "EHLO mail-wr0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751636AbdITQHt (ORCPT ); Wed, 20 Sep 2017 12:07:49 -0400 Received: by mail-wr0-f195.google.com with SMTP id k20so1756348wre.1; Wed, 20 Sep 2017 09:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=B90NU7U4zHp6u+9efa7u9L70iZEH/5Tg0XS08fmB5NE=; b=XB+QDGMYkEgQHZ0v2GhJ7H9qqDJcuef//+ADfKTqBsj7MEt13YZxmvyavPhcFwT7Hr vV2XC906WgNGYv3WL56ntJFh2cAmULkoClWSUIL+Zh34BS+Casqr1wgGLppuPAsIVc8s EqH6D9k94zyTRevS+9HsGC0luFbs6+CUz6mcI2Pf0eYuxPZfG3UPkVW/MG81XrlJ5duV PSJkDfNizSAeg3uoTjJm+ATyX1MsraBkATQj3OlQr04tmjDqTigIoc4H0uZocrX4XTFW C+yDoE3r6/U5jeUzGvBeCNUmHF63ES3pcKMeUGQuDpA5x1erVJRqXNssw3w3c5unt5RJ rJsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=B90NU7U4zHp6u+9efa7u9L70iZEH/5Tg0XS08fmB5NE=; b=i/uFQNltZyMd/i9isV9sHyMjSFqrD4kXMTOCn4l1j5q+wdbEUEUJYl3fo0ehf57uAu FJ7OHTVJ58RuxQl2dNMFgiiw9WeNCIcJcFOZfswsSpwXsVQNFll/g2eFGmrT01rZaGXP baUUsUBRxe0vnK06RXHlIdZGwm8SD1hrh+qKHCJ5oHBi9ZD1I1uYaClSOLaMYs1bbkQH hg9gBT3Q1oxCgtmKQwy3OuRl3ohBHBRmRf1RKQRsuOHbwGxcWQe0rExRyTVAMYJ92c/q 0Gt9HX86784deWM4p/PZNac2F0eJ62XfkFHawIJqB7hTUVz7TVPBPrrGKX3M6G9beQIh 07qQ== X-Gm-Message-State: AHPjjUi1LNxzPxlINlbzXaAbnUzJbNUMQPEDt/uGokmDXZHYqlgH5rwI 4ZLmK5nOrep1luloCSIUFoPEn70= X-Google-Smtp-Source: AOwi7QDEJDtrNY+M4xO5oUuHIYnfXN3P9BFuYsmUbyhXMx4r/RVDSl7DLskzc/Qw5c3qZxkwlysHgw== X-Received: by 10.223.134.231 with SMTP id 36mr5328072wry.141.1505923667963; Wed, 20 Sep 2017 09:07:47 -0700 (PDT) Received: from kmo-pixel ([2a03:2260:3004:25:f7d8:c71a:9624:22eb]) by smtp.gmail.com with ESMTPSA id w2sm2209239wrb.67.2017.09.20.09.07.44 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 20 Sep 2017 09:07:45 -0700 (PDT) Date: Wed, 20 Sep 2017 18:07:35 +0200 From: Kent Overstreet To: Coly Li Cc: linux-bcache@vger.kernel.org, linux-block@vger.kernel.org, Nix , Kai Krakow , Eric Wheeler , Junhui Tang , stable@vger.kernel.org Subject: Re: [PATCHv2] bcache: option for allow stale data on read failure Message-ID: <20170920160735.jp4riq7x3qc472px@kmo-pixel> References: <20170919222433.24336-1-colyli@suse.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20170919222433.24336-1-colyli@suse.de> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed, Sep 20, 2017 at 06:24:33AM +0800, Coly Li wrote: > When bcache does read I/Os, for example in writeback or writethrough mode, > if a read request on cache device is failed, bcache will try to recovery > the request by reading from cached device. If the data on cached device is > not synced with cache device, then requester will get a stale data. > > For critical storage system like database, providing stale data from > recovery may result an application level data corruption, which is > unacceptible. But for some other situation like multi-media stream cache, > continuous service may be more important and it is acceptible to fetch > a chunk of stale data. > > This patch tries to solve the above conflict by adding a sysfs option > /sys/block/bcache/bcache/allow_stale_data_on_failure > which is defaultly cleared (to 0) as disabled. Now people can make choices > for different situations. IMO this is just a bug, I'd rather not have an option to keep the buggy behaviour. How about this patch: commit 2746f9c1f962288d8c5d7dabe698bf7b3fddd405 Author: Kent Overstreet Date: Wed Sep 20 18:06:37 2017 +0200 bcache: Don't recover from IO errors when reading dirty data Signed-off-by: Kent Overstreet diff --git a/drivers/md/bcache/request.c b/drivers/md/bcache/request.c index 382397772a..c2d57ef953 100644 --- a/drivers/md/bcache/request.c +++ b/drivers/md/bcache/request.c @@ -532,8 +532,10 @@ static int cache_lookup_fn(struct btree_op *op, struct btree *b, struct bkey *k) PTR_BUCKET(b->c, k, ptr)->prio = INITIAL_PRIO; - if (KEY_DIRTY(k)) + if (KEY_DIRTY(k)) { s->read_dirty_data = true; + s->recoverable = false; + } n = bio_next_split(bio, min_t(uint64_t, INT_MAX, KEY_OFFSET(k) - bio->bi_iter.bi_sector),