Received: by 10.223.185.116 with SMTP id b49csp6329824wrg; Wed, 28 Feb 2018 07:40:36 -0800 (PST) X-Google-Smtp-Source: AH8x226naPPSV1nQPwDHVm310gRhhd5VWckdJX8gHCCl73NCMsjZAKvzxX8js3+M6pyPmgZ+wagc X-Received: by 10.98.18.143 with SMTP id 15mr18307832pfs.104.1519832436221; Wed, 28 Feb 2018 07:40:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519832436; cv=none; d=google.com; s=arc-20160816; b=Oi62LDrM15hzYMnS3aSIKuUJA6bbDPwV1uO3vqNYvFoEgOon61lUAQtYbml8UuqMPC 0i1640lKWUE1sItg3e/yMVseD9l2MitjQ9xFohYLlUibtSezJsjzQVp9LKwFRx/NB4i+ VZbWQAkqrd6fOU7sMgO6m44fGTKW1Se01S2DmhoBQzzi1CxRUdRLADUXy6UF9U3iEhzW pdY4OmzNKQ3I2u5pI/7Ic+4LEU9XQOn5ekAmgsA2uwHqURLd8b/8sKhHcYplyIE3X2xB NRygL/BpctMc8rp/lmPgVorjfWrQhI0Q0mDGacyTEpjiSGHVxSVkZwB+aBxUt+geZyry k2Cw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=iMuhM/dCmn4lsZPR6zMBtI7ngwO27Xw2d87cOHp+6/c=; b=AjF/21YSe/9HX7uRuFqcWgwva5yLiGI23cc3ItGEKWtLGNjNBSB6X1YPNZOIUiPkEg Xqq6/Z9OZBAmLQkWG9M5t7HMrKfh8aXHkdp4wleKMJOtJijfZ9kYV6iYVKjfv6Y9GFgs a2qQiLYbhF+yjqB8KOQ2gaHR6lSF/3H44mcDW9HpNeDV8PD84zeLj1AyTbBLff8JYZbX hQoYKQDoI4E5LbhWINCOe0q1uoF88e2zDaP9+CrIYLof0xApIQiE93Ms15uII9ElIRrV k+R76P93xFLGgQ/CClg0874xHDqo40hh7hAKk1n5M0q8ldI1Hq5it+FfRhOmjA3c5yyH fQlA== 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 m13si1145183pgd.641.2018.02.28.07.40.21; Wed, 28 Feb 2018 07:40:36 -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 S933366AbeB1PjK (ORCPT + 99 others); Wed, 28 Feb 2018 10:39:10 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:33212 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932292AbeB1PW1 (ORCPT ); Wed, 28 Feb 2018 10:22:27 -0500 Received: from [2a02:8011:400e:2:6f00:88c8:c921:d332] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1er3Yg-0006Xk-PN; Wed, 28 Feb 2018 15:22:19 +0000 Received: from ben by deadeye with local (Exim 4.90_1) (envelope-from ) id 1er3Ye-0008SL-Uz; Wed, 28 Feb 2018 15:22:16 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Omar Sandoval" , "Qu Wenruo" , "David Sterba" Date: Wed, 28 Feb 2018 15:20:18 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 064/254] Btrfs: disable FUA if mounted with nobarrier In-Reply-To: X-SA-Exim-Connect-IP: 2a02:8011:400e:2:6f00:88c8:c921:d332 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.55-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Omar Sandoval commit 1b9e619c5bc8235cfba3dc4ced2fb0e3554a05d4 upstream. I was seeing disk flushes still happening when I mounted a Btrfs filesystem with nobarrier for testing. This is because we use FUA to write out the first super block, and on devices without FUA support, the block layer translates FUA to a flush. Even on devices supporting true FUA, using FUA when we asked for no barriers is surprising. Fixes: 387125fc722a8ed ("Btrfs: fix barrier flushes") Signed-off-by: Omar Sandoval Reviewed-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba [bwh: Backported to 3.16: - I/O flag names are different, and are combined with the operation type - Use the do_barrier parameter instead of checking the NOBARRIER option again] Signed-off-by: Ben Hutchings --- --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -3140,6 +3140,7 @@ static int write_dev_supers(struct btrfs int errors = 0; u32 crc; u64 bytenr; + int op_flags; if (max_mirrors == 0) max_mirrors = BTRFS_SUPER_MIRROR_MAX; @@ -3204,10 +3205,10 @@ static int write_dev_supers(struct btrfs * we fua the first super. The others we allow * to go down lazy. */ - if (i == 0) - ret = btrfsic_submit_bh(WRITE_FUA, bh); - else - ret = btrfsic_submit_bh(WRITE_SYNC, bh); + op_flags = REQ_SYNC | REQ_NOIDLE; + if (i == 0 && do_barriers) + op_flags |= REQ_FUA; + ret = btrfsic_submit_bh(WRITE | op_flags, bh); if (ret) errors++; }