From patchwork Tue Mar 5 16:40:18 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chris Mason X-Patchwork-Id: 2220431 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id 619534020C for ; Tue, 5 Mar 2013 16:40:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757879Ab3CEQk2 (ORCPT ); Tue, 5 Mar 2013 11:40:28 -0500 Received: from dkim2.fusionio.com ([66.114.96.54]:52743 "EHLO dkim2.fusionio.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757786Ab3CEQkV convert rfc822-to-8bit (ORCPT ); Tue, 5 Mar 2013 11:40:21 -0500 Received: from mx1.fusionio.com (unknown [10.101.1.160]) by dkim2.fusionio.com (Postfix) with ESMTP id 313C19A067A for ; Tue, 5 Mar 2013 09:40:21 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fusionio.com; s=default; t=1362501621; bh=RR+NOcJzTo6mtJ8S6T0csQ4ztygHiKyL2HLW8yliNdQ=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=caF5AxqS8qnGO7bj3hM5EprjOZJIXsrRkxk+jbUWMi24M+oTioBz3e1B8GTuURq5x aYo5D/qbyTghINI0n8WbaWG+Rx3v35FPPdXBrw8AS3vpNrDIR/1qUofPmqukYepEJ7 ZaRlqpOl3gB7+PnvD+9NnrpjBiUxceThL7WNW8So= X-ASG-Debug-ID: 1362501620-03d6a5664ac6400001-6jHSXT Received: from mail1.int.fusionio.com (mail1.int.fusionio.com [10.101.1.21]) by mx1.fusionio.com with ESMTP id s289CzQsMEDiEbBq (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Tue, 05 Mar 2013 09:40:20 -0700 (MST) X-Barracuda-Envelope-From: clmason@fusionio.com Received: from localhost (67.247.72.189) by mail.fusionio.com (10.101.1.19) with Microsoft SMTP Server (TLS) id 8.3.83.0; Tue, 5 Mar 2013 09:40:19 -0700 Date: Tue, 5 Mar 2013 11:40:18 -0500 From: Chris Mason To: Chris Mason CC: Stefan Behrens , Linux Btrfs List , "zab@redhat.com" Subject: Re: [BUG] during balance operation, WARNING: at fs/btrfs/relocation.c:1624 replace_file_extents+0x74b/0x7e0 [btrfs]() Message-ID: <20130305164018.GH30680@shiny.masoncoding.com> X-ASG-Orig-Subj: Re: [BUG] during balance operation, WARNING: at fs/btrfs/relocation.c:1624 replace_file_extents+0x74b/0x7e0 [btrfs]() Mail-Followup-To: Chris Mason , Chris Mason , Stefan Behrens , Linux Btrfs List , "zab@redhat.com" References: <5134D8D7.9000501@giantdisaster.de> <20130304193137.GA30680@shiny.masoncoding.com> <5135DE09.4080605@giantdisaster.de> <20130305151121.GE30680@shiny.masoncoding.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20130305151121.GE30680@shiny.masoncoding.com> User-Agent: Mutt/1.5.21 (2011-07-01) X-Barracuda-Connect: mail1.int.fusionio.com[10.101.1.21] X-Barracuda-Start-Time: 1362501620 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://10.101.1.180:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at fusionio.com X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Spam-Score: -2.01 X-Barracuda-Spam-Status: No, SCORE=-2.01 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_SA_TO_FROM_DOMAIN_MATCH X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.124334 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Tue, Mar 05, 2013 at 08:11:21AM -0700, Chris Mason wrote: > inux 3.9 RC1. > > >> > > >> #!/bin/sh > > >> mkfs.btrfs -f /dev/sdl /dev/sdk -m raid1 -d raid1 -l 16384 > > >> mount /dev/sdl /mnt > > >> dd if=/dev/urandom of=/mnt/urandom.1GB bsM count0 & > > >> dd if=/dev/zero of=/mnt/zero.4GB bsM count@0 & > > >> (cd ~/kernel-src; tar cf - fs) | (cd /mnt && tar xf -) > > >> wait > > >> > > >> ((cd ~/kernel-src; tar cf - drivers) | (cd /mnt && tar xf -)) & > > >> sleep 5 > > >> btrfs fi balance start /mnt > > > > > > This doesn't look new, are you able to trigger it with an older kernel? > > > > > > > git bisect identifies the following post v3.8 commit to be the one: > > Is your dd running fallocate? Trying to figure out how this is related. So the preallocation came from balance, which is preallocating because it requires us to make an extent exactly the same size as the one we are replacing. Zach's commit broke that rule, which means I finally get to send him a tshirt to celebrate his first btrfs bug. Looking through all other callers, min_bytes is always either the sector size or the total allocation requested, so I've done this and pushed it to for-linus. Stefan, many thanks for bisecting and testing the patch. commit 154ea2893002618bc3f9a1e2d8186c65490968b1 Author: Chris Mason Date: Tue Mar 5 11:11:26 2013 -0500 Btrfs: enforce min_bytes parameter during extent allocation Commit 24542bf7ea5e4fdfdb5157ff544c093fa4dcb536 changed preallocation of extents to cap the max size we try to allocate. It's a valid change, but the extent reservation code is also used by balance, and that can't tolerate a smaller extent being allocated. __btrfs_prealloc_file_range already has a min_size parameter, which is used by relocation to request a specific extent size. This commit adds an extra check to enforce that minimum extent size. Signed-off-by: Chris Mason Reported-by: Stefan Behrens --- 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/inode.c b/fs/btrfs/inode.c index ecd9c4c..13ab4de 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -8502,6 +8502,7 @@ static int __btrfs_prealloc_file_range(struct inode *inode, int mode, struct btrfs_key ins; u64 cur_offset = start; u64 i_size; + u64 cur_bytes; int ret = 0; bool own_trans = true; @@ -8516,8 +8517,9 @@ static int __btrfs_prealloc_file_range(struct inode *inode, int mode, } } - ret = btrfs_reserve_extent(trans, root, - min(num_bytes, 256ULL * 1024 * 1024), + cur_bytes = min(num_bytes, 256ULL * 1024 * 1024); + cur_bytes = max(cur_bytes, min_size); + ret = btrfs_reserve_extent(trans, root, cur_bytes, min_size, 0, *alloc_hint, &ins, 1); if (ret) { if (own_trans)