From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7CCAB3D1CAA for ; Mon, 20 Jul 2026 10:37:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784543851; cv=none; b=SpudLHTLh0qRSk9uMG93IDyV2IEuEkP44ueM0DefGdZOmq9h786OyQdmnrvZK9VLRF1lALEW5HY9ymRw8n4w7AAKZTbs6FC8DDAr1KAFLuKQcfcSn5fFWIhpZu+BdfBWlZLIZAGcCxJwh3q+enwLQK8tf57V1J81r9pOatc2shY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784543851; c=relaxed/simple; bh=HsXP1SOgYQKGRu4YP/BzK3zeihpC3V59WcJ9CVZ0944=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=JaYhShvdoJEhuM3tuejpGRq2zh/KGjR44o3yabctvlNX74vf//0xTvan0RySq3ASe8OOWfv6phibpASz/7ItLiOZsEfpsuG6LyV851kqQk/BstXgHmb00wDKytv7MoDDt2oBRu/6+vvhwmtawVCXwm9XmA3j1BAOzrGuPJzFASo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=readmodwrite.com; spf=none smtp.mailfrom=readmodwrite.com; dkim=pass (2048-bit key) header.d=readmodwrite-com.20251104.gappssmtp.com header.i=@readmodwrite-com.20251104.gappssmtp.com header.b=v/LWc+TF; arc=none smtp.client-ip=209.85.221.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=readmodwrite.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=readmodwrite.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=readmodwrite-com.20251104.gappssmtp.com header.i=@readmodwrite-com.20251104.gappssmtp.com header.b="v/LWc+TF" Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-47f7444576cso701918f8f.0 for ; Mon, 20 Jul 2026 03:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=readmodwrite-com.20251104.gappssmtp.com; s=20251104; t=1784543847; x=1785148647; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=9Ob60SlvDtMBq7kgwRG6216brqjU5lsAVw+EombhPOE=; b=v/LWc+TF3dHJ5iNfM/KrMQkku/7xqwBPwOgdQ07W+RXS7DvgyTAYPUW/6mcx1GsuRc +04cRzEaTxt8IOYhOlzu52hplodcbhjNqjoyb5QUCw4SgCrLh8GGQYLtOet9e36MzwXo BMjU0ZFBYaJm3miVqg/EOen+BxCrRVYdOWI20w51zm4UPrASqt2uaw+a+ZybdFM7iTap 5Kxw29yPrnN+pzi8pHWa/VRTE6FfxIePhXnwEFI5xuo94mJ3e/xdLlPfXLuXi86oxwuu U4ugJ9zHreczmTh+UYyb4BiNIpK5u1RhleYhoeH3bv5yyXbuiITP5DtTtacybTg+IJw3 DSzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784543847; x=1785148647; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=9Ob60SlvDtMBq7kgwRG6216brqjU5lsAVw+EombhPOE=; b=Y9oT9J4BpdTYtIb1Kj9ArDZw/Bihv+8Q0AtpBIEriNWlokxwgeJ8mEUasX9/jzJ6vr RTR11eRiERoLK0MzB/AEhgCTVTlKHB7Gy5NdOIH6csNC0R0++RzvYA6+vAgIgYJj598O 6sSN6uWMo2uiUmHbY/g5D/rRJWw4w2NKts4PfVpIRDiIp+K0mbZuw18+WNH/FulaaO0S PUlcyY2PtLquo+3l23GUgH/pWhOUmhNX+ckHFplxl19IVDbDWKZROEVp0hX+1cqO7t0r jK7oHIrjdoUcFnVTiQ4lVDQy+v7iW77twTf273+1jJ58ID+p3KBgj8KiZLoGmaot6bHc H8Qw== X-Forwarded-Encrypted: i=1; AHgh+RqDRHsrHqL60NAPppjfR7i+++VN8TnjnJTp/oX2mNdN2EbK/lQpx7jp7AmnlXwPHovfcuBttoyjCL0BgtQ=@vger.kernel.org X-Gm-Message-State: AOJu0Yyfsq6DXcqe3VDlF8a+NEfhy++XnKnRLORe1cBOjmqNrmvWORn7 egqD7t7csAITmdJxxM+C+b8qPNt3MHgK1jxPceimPx4MGeEehxbsupvqhUCK53o39CdeAXltNJz A/muqfp0= X-Gm-Gg: AR+sD13vHgPpsKO1ejIYl9MRh9Bm1VDd+H379gBNlni6SJjQKC1CHPlxehA+bSrfy9X wVbaq1FX6Pp8aatBsEPRFQg3JrndbyMwF44iIEKl40U5FTNUb7XDXBlIbymBSMj6JGvgYkl7qqb ha4mH+BK++qsVc5KyWJJJYjE7TRGv3M6pMhTFftFzA4nBkfFwOiDUNsBfMG/Phtw0N7ht1QcHMB NXFySuCxnAz8tmTekPSP8Gj7MJR3e1B67+MIeI+WBTPhV0QrL5XdZJQoX4jh8UbVmHkvhvxY9fj bp8vT4dq4i7BWvwMzsiZAA4kcoBlN2veGi11QEvNEuCGuMMbRiSkln1d5WvG/ucLhtY1n+CLVx3 ItuEe6xRDNjPGGclf1fXPdjDWfw/dxWYO3JQYfQNrsR0XGAMEsehqtr+0I2ZOhdoE X-Received: by 2002:a05:6000:1786:b0:46f:7d90:8125 with SMTP id ffacd0b85a97d-47f62305d3cmr15731928f8f.15.1784543847159; Mon, 20 Jul 2026 03:37:27 -0700 (PDT) Received: from localhost ([2a09:bac6:37a8:1cdc::2e0:ea]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47f63ed2313sm28266750f8f.23.2026.07.20.03.37.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Jul 2026 03:37:26 -0700 (PDT) Date: Mon, 20 Jul 2026 11:37:25 +0100 From: Matt Fleming To: Brian Foster Cc: linux-xfs@vger.kernel.org, Carlos Maiolino , "Darrick J . Wong" , Dave Chinner , Christoph Hellwig , linux-kernel@vger.kernel.org, kernel-team@cloudflare.com Subject: Re: [BUG] xfs: sparse inode allocation can trip i != 1 after AGFL growth Message-ID: References: <20260717130429.1838767-1-matt@readmodwrite.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Jul 17, 2026 at 01:55:42PM -0400, Brian Foster wrote: > On Fri, Jul 17, 2026 at 02:04:29PM +0100, Matt Fleming wrote: > > > > The failure sequence seems to be: > > > > 1. AG0 has no free inodes, so inode allocation needs a new chunk. > > 2. Full chunk allocation cannot fit. > > 3. Sparse chunk allocation can fit and passes the old AGFL minimum check. > > 4. Removing the sparse extent from free space grows both bnobt and cntbt. > > I assume this means we happen to alloc a sparse chunk out of the middle > of a free extent, causing an additional record and thus splits in both > trees. Yep, exactly. > It also looks like we set args.minleft = igeo->inobt_maxlevels in the > chunk alloc path, presumably with the intent to leave enough blocks > around for inode record insertion. I assume the above available value is > prior to the sparse chunk alloc. It would be interesting to see what the > same values/calculations are after the chunk alloc at the time of the > inobt block alloc that fails. Before sparse inode allocation: pagf_freeblks: 2514 pagf_flcount: 8 levels: bno/cnt/rmap = 1/1/2 reservation: 2505 minleft: 2 min_freelist: 8 AGFL credit: min(8, 8) = 8 available: 2514 + 8 - 2505 - 8 - 2 = 7 request: minlen=4 align=4 slop=0 alloc_len = 4 + (4 - 1) + 0 = 7 So the sparse inode allocation only just passes the allocator check. After sparse inode allocation, at the failing inobt split allocation: pagf_freeblks: 2510 pagf_flcount: 4 levels: bno/cnt/rmap = 2/2/2 reservation: 2505 minleft: 0 min_freelist: 12 AGFL credit: min(4, 12) = 4 available: 2510 + 4 - 2505 - 12 - 0 = -3 request: minlen=1 So after removing the 4-block sparse extent, bnobt/cntbt have grown, AGFL has dropped, min_freelist has increased from 8 to 12, and the later single-block inobt allocation has no available space. Thanks, Matt