From patchwork Fri Aug 5 20:03:43 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gabriel C X-Patchwork-Id: 9265701 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 1CEE060754 for ; Fri, 5 Aug 2016 20:04:56 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id F2B0728068 for ; Fri, 5 Aug 2016 20:04:55 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D2CE528138; Fri, 5 Aug 2016 20:04:55 +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.8 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, T_DKIM_INVALID 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 687F828068 for ; Fri, 5 Aug 2016 20:04:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1425056AbcHEUEe (ORCPT ); Fri, 5 Aug 2016 16:04:34 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:36571 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1946874AbcHEUE2 (ORCPT ); Fri, 5 Aug 2016 16:04:28 -0400 Received: by mail-wm0-f68.google.com with SMTP id x83so5138177wma.3 for ; Fri, 05 Aug 2016 13:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=UuYxURhvoP/6bYKh+ylwuMie2GANassBrhg+ZjxmTHw=; b=eRZQihltmWWR9/LW3AGIKAZF0yy2xRWhwnOSjqoaVWC3zn0QQkCagcesFDu9Jw+zBe HbO7DuPF+2uxC22AmoJyQRBJwaxy63MNtTHClY3LUZV1llmhnmw+eIQEvouC+zRxuT9B 2Jn05RWx+3w/6gFLQf1V2XIRwRm6Cmk8AFOv5OHmqUl8kL4BEXncZkZdD8TMRTjAQjQA ljUdevuieHGNnF5OOqhBdj0Jnc5KvWwwSL1Cz+fp7fc1MfNmNsw1xMt1PxvmqipGwhM5 6vRQf+MEAQ8v3CpB2Hb/O8yk/7D7lnPvFlBe0BaA/AL+uUaM2KZ3F6Cz9sebc27Y+EkQ 7JVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=UuYxURhvoP/6bYKh+ylwuMie2GANassBrhg+ZjxmTHw=; b=mqJ5jY/RysZwS1/4kit5SA3IOPl4nkTqPN8Sy8/W5VfwCdCMCMGgSThNb+BghFpvAW sQ7wExr/hJMXpwtPWc8N0U0sRH2CCfZ/qmNouGX2PpDPDdK3ARztNlb3thQnhGixfOL+ hdIP9V5ebRI40IHX6YT75FrRy2C+ahrz6CkanhRJUtbb4vGRr1cmxk4jcAB+gC+Oh9YQ +oD2WNTDE/PaRMbSyaCL6wYGCHCn+qgL247jVsaU9U0hW1XFZUO3RG4tBRVmg9dLme09 PqYF7K6h63Grof9Jl+1GqJewhUrwLoybQtUpgQkLA49Ttf2yGVONXNs8KgWVjkEL8Js5 XUXA== X-Gm-Message-State: AEkoouvYOdCgl02u3UhvcsQH1w0qoCusZ9d3m/t/Kgz8L3rG/hvNnSnBNaGr1/aBJTPLWQ== X-Received: by 10.194.136.196 with SMTP id qc4mr81392335wjb.136.1470427466686; Fri, 05 Aug 2016 13:04:26 -0700 (PDT) Received: from [192.168.178.79] (x4e314108.dyn.telefonica.de. [78.49.65.8]) by smtp.gmail.com with ESMTPSA id pm1sm19273367wjb.40.2016.08.05.13.04.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Aug 2016 13:04:17 -0700 (PDT) Subject: Re: 6TB partition, Data only 2TB - aka When you haven't hit the "usual" problem To: Lutz Vieweg , "cheater00 ." , "Austin S. Hemmelgarn" , Hugo Mills , Chris Murphy , Btrfs BTRFS , russell@coker.com.au References: <20160109202659.GC6060@carfax.org.uk> <20160109210429.GD6060@carfax.org.uk> <5693A8B3.2090508@gmail.com> <57A372F3.5090400@5t9.de> From: Gabriel C Message-ID: <5ee26e48-d949-502e-5884-6369c9e6b278@gmail.com> Date: Fri, 5 Aug 2016 22:03:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <57A372F3.5090400@5t9.de> Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 04.08.2016 18:53, Lutz Vieweg wrote: > > I was today hit by what I think is probably the same bug: > A btrfs on a close-to-4TB sized block device, only half filled > to almost exactly 2 TB, suddenly says "no space left on device" > upon any attempt to write to it. The filesystem was NOT automatically > switched to read-only by the kernel, I should mention. > > Re-mounting (which is a pain as this filesystem is used for > $HOMEs of a multitude of active users who I have to kick from > the server for doing things like re-mounting) removed the symptom > for now, but from what I can read in linux-btrfs mailing list > archives, it pretty likely the symptom will re-appear. > > Here are some more details: > > Software versions: >> linux-4.6.1 (vanilla from kernel.org) ... > > dmesg output from the time the "no space left on device"-symptom > appeared: > >> [5171203.601620] WARNING: CPU: 4 PID: 23208 at fs/btrfs/inode.c:9261 btrfs_destroy_inode+0x263/0x2a0 [btrfs] .... > ... >> [5171230.306037] WARNING: CPU: 18 PID: 12656 at fs/btrfs/extent-tree.c:4233 btrfs_free_reserved_data_space_noquota+0xf3/0x100 [btrfs] Sounds like the bug I hit too also .. To fix this you'll need : crazy@zwerg:~/Work/linux-git$ git show 8b8b08cbf commit 8b8b08cbfb9021af4b54b4175fc4c51d655aac8c Author: Chris Mason Date: Tue Jul 19 05:52:36 2016 -0700 Btrfs: fix delalloc accounting after copy_from_user faults Commit 56244ef151c3cd11 was almost but not quite enough to fix the reservation math after btrfs_copy_from_user returned partial copies. Some users are still seeing warnings in btrfs_destroy_inode, and with a long enough test run I'm able to trigger them as well. This patch fixes the accounting math again, bringing it much closer to the way it was before the sectorsize conversion Chandan did. The problem is accounting for the offset into the page/sector when we do a partial copy. This one just uses the dirty_sectors variable which should already be updated properly. Signed-off-by: Chris Mason cc: stable@vger.kernel.org # v4.6+ --- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c index f3f61d1..bcfb4a2 100644 --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -1629,13 +1629,11 @@ again: * managed to copy. */ if (num_sectors > dirty_sectors) { - /* - * we round down because we don't want to count - * any partial blocks actually sent through the - * IO machines - */ - release_bytes = round_down(release_bytes - copied, - root->sectorsize); + + /* release everything except the sectors we dirtied */ + release_bytes -= dirty_sectors << + root->fs_info->sb->s_blocksize_bits; + if (copied > 0) { spin_lock(&BTRFS_I(inode)->lock); BTRFS_I(inode)->outstanding_extents++;