From nobody Fri Apr 3 03:13:50 2026 Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) (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 B62F414A60F for ; Mon, 16 Feb 2026 22:17:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771280255; cv=none; b=V7uLQUZE8o84ajsdJ5YXaxRKMxiyqzAZ/W86Him/aNgNXuJYX5n7IlNkGGjo+itKIIj0tCya/c/Pevvpv8+BKjrhQ7fKGGYOuu9Enxfk9ZX4cXOvyzUiofvYj/7GuHZAqlhPDKZyZpr6RYXvAret6NtrEQMMtux/Fea0s3AA/w0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771280255; c=relaxed/simple; bh=NjtsnE0mKUEBs0uRzaeL+DClyCEXBupMB4mNFSaNS6k=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=sVNvvBptr1egkcOmeu6RZfOg+enPhiEPfSmvbJj+xFgRHbGqb0+IYJyXYDIfpykA/X3NT+lspbQD6l01dROPQ3Wr35ZCqVB9yw0jaC6LNdZ0iMeSURpYHIPDuc1E2SNuHnEGFlnQGmzc9PV+QWO2JkYa+YPU6OdkPUkuux8sw+E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=YMU9wx6n; arc=none smtp.client-ip=209.85.214.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="YMU9wx6n" Received: by mail-pl1-f172.google.com with SMTP id d9443c01a7336-2a95bfdb31eso15403015ad.3 for ; Mon, 16 Feb 2026 14:17:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771280254; x=1771885054; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=HKAIaxxIN9CmwcPqgGwKxiWPmmI4kX+9G0DKtHNSc/c=; b=YMU9wx6nZ1yD6c4VwtnHOnw1ouft0rvMwcPlBw498Izzh6SyQdMXMnZJ4JKG+wyMwn Q+Oqfdi6xJ9obGocAyPphgFR2r3Cf1xt4T+KMGVkjCflj3yTZTW2dNe1oUTEMZb8LmX/ fO9dkh0zJeF80HrMX/U+el2QXZf6A/WcOtbP6REdq3ppAVxm1c8Qto2KvxuVogJdkzAV xIqCvlqQZQmS0mFPotu7YfasYlUz4OakFR5W6pkcBvPwVxtU0XKB+VP9U2ugVyTLsReI YywTLziEsoUeORKD42TIDpb/mJXsXUB4tLJT5VOj9hPQt3XKXQC2K45vr1KfC6084vC1 0D3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771280254; x=1771885054; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=HKAIaxxIN9CmwcPqgGwKxiWPmmI4kX+9G0DKtHNSc/c=; b=BVW2AaP7wROPmhSZHaJ125U4Yi1dZRrM1bmVP2XgXxeUu6basNJ4jKknl9QwCDKYZ6 yu6ZjSx2re/Rgp+gf4vbNOTadWP3JCnkM9RtB3fSIiPBlQMG4xZDg8/TTCziZEkKeCz2 Qssp0ZQL1S6OG7KTd7eMuJyvi5s1iYNfJZ6lgVIZchDbEudIWMUsUphVeoMmMhBFAorM U0lqi3CJ8PqP0SJyb2c+VDNpEj9N40uHCV8zifZZ1embFhmUvS+mMyUr5YLxR7sAbjOZ vSGkmlGq6CArP0RtoJZBthGP2nfrIXX1SW1jKmQXvoCLu8toZ9vLhAfwmc58mu1ppvvW V2fA== X-Forwarded-Encrypted: i=1; AJvYcCUM8vJM9HxsCqDTGR35fDTMU1b6h2xQeu3yY0l170yGZM4/hGuhEmvo+SJfLy+W8bZ2DOE6Mw2ZZPtP5Kk=@vger.kernel.org X-Gm-Message-State: AOJu0YzWUdmC2XqU32HsvRklfb6lHYE1komfbebPqYHfhGrYrEFNBBrc X2MGHhsm9CO6YDG/avSdafWKU4JH3Kl/QLgiYHQQqGzMsQaMMh/XuWR1zwBWRCoF X-Gm-Gg: AZuq6aJuUwdD0y4mthR6xYKOL5JCiG6ciV6azF3OwQx3+XxBsaVkqQPiHiSLiV3xGbE EqjUijf261Ukg1bcrk1WHYxYUW77HiBjyAHGvJoxNmZU0ewsOCtQ+Npa7IiLES1nEctPWIspo6S FS9GKbfgXyDdYuM4/0tRhgvraCgLma147xllyLesRn3DLL6xjPJRpPfHexQfLAQ3jFwUugdiEgT 4YLV7JlIDJlbuKiGGO51BGBaef+Eh2W3RUH8VJRh8GDWd/Iu+vKnsQknW4ywSmhy+WW6Ny9cCJI TLry3n4oXOZg+nOVgtLBaEjrDx+6QkycA6uKJUc3gi7qQf5CpblxKQGZ/3G5JHp9hOiBTCC8q+6 z+0M+3IQXaMc0FDA2uKiWmEW1CpVF4zEk/NpOQz7zolixivsSJ04uglt/PFXroSUjHj1j9byvGV i6bnG11mcsg9WQ4lh6fdgs8jGlpMkF/GreBwg/zIBat439sF6LjIVMC0yoEC4iolYTm039oxfAp tCV X-Received: by 2002:a17:902:db0f:b0:2a9:3397:2647 with SMTP id d9443c01a7336-2ab5060da04mr113511355ad.50.1771280253914; Mon, 16 Feb 2026 14:17:33 -0800 (PST) Received: from localhost.localdomain (1-173-18-181.dynamic-ip.hinet.net. [1.173.18.181]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ad1a6fa229sm75952695ad.18.2026.02.16.14.17.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Feb 2026 14:17:33 -0800 (PST) From: jkchen X-Google-Original-From: jkchen To: Chris Mason , Josef Bacik , David Sterba Cc: linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, jkchen Subject: [PATCH] btrfs: check snapshot_force_cow earlier in can_nocow_file_extent Date: Tue, 17 Feb 2026 06:16:32 +0800 Message-ID: <20260216221632.23087-1-jkchen@ugreen.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When a snapshot is being created, the atomic counter snapshot_force_cow is incremented to force incoming writes to fallback to COW. This is a critical mechanism to protect the consistency of the snapshot being taken. Currently, can_nocow_file_extent() checks this counter only after performing several checks, most notably the expensive cross-reference check via btrfs_cross_ref_exist(). btrfs_cross_ref_exist() releases the path and performs a search in the extent tree or backref cache, which involves btree traversals and locking overhead. This patch moves the snapshot_force_cow check to the very beginning of can_nocow_file_extent(). This reordering is safe and beneficial because: 1. args->writeback_path is invariant for the duration of the call (set by caller run_delalloc_nocow). 2. is_freespace_inode is a static property of the inode. 3. The state of snapshot_force_cow is driven by the btrfs_mksnapshot process. Checking it earlier does not change the outcome of the NOCOW decision, but effectively prunes the expensive code path when a fallback to COW is inevitable. By failing fast when a snapshot is pending, we avoid the unnecessary overhead of btrfs_cross_ref_exist() and other extent item checks in the scenario where NOCOW is already known to be impossible. Signed-off-by: jkchen Reviewed-by: Filipe Manana --- fs/btrfs/inode.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 845164485..3549031f3 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -1921,6 +1921,11 @@ static int can_nocow_file_extent(struct btrfs_path *= path, int ret =3D 0; bool nowait =3D path->nowait; =20 + /* If there are pending snapshots for this root, we must COW. */ + if (args->writeback_path && !is_freespace_inode && + atomic_read(&root->snapshot_force_cow)) + goto out; + fi =3D btrfs_item_ptr(leaf, path->slots[0], struct btrfs_file_extent_item= ); extent_type =3D btrfs_file_extent_type(leaf, fi); =20 @@ -1982,11 +1987,6 @@ static int can_nocow_file_extent(struct btrfs_path *= path, path =3D NULL; } =20 - /* If there are pending snapshots for this root, we must COW. */ - if (args->writeback_path && !is_freespace_inode && - atomic_read(&root->snapshot_force_cow)) - goto out; - args->file_extent.num_bytes =3D min(args->end + 1, extent_end) - args->st= art; args->file_extent.offset +=3D args->start - key->offset; io_start =3D args->file_extent.disk_bytenr + args->file_extent.offset; --=20 2.43.0