From nobody Wed Oct 1 23:27:54 2025 Received: from out-189.mta1.migadu.com (out-189.mta1.migadu.com [95.215.58.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8822E1EC01B for ; Fri, 26 Sep 2025 07:46:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.189 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758872810; cv=none; b=P5WwXAYuohedaZaZ7GQ9Alj1b7opVTQRzs6tjwMFX7/dGU8O31ZhzRj0mi5GTK2wD7iIht6g31ipOLnktXqjmgpe6ZD/JCHWBIUj2y8D1i5ZULC1F7W0jjY33PEDBcIYGzaJ+KlpmSTzZ5e8UkgRdneGDz4d3Hb0Vos4VyMQp6M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758872810; c=relaxed/simple; bh=6O4UDmOYFlgQss9hMUmj13URvsHTcqWnHmUqkWhSfsA=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=h5nnkecsY6gnVp7SyhLMDHVy4wyhth6jWV7319ixzEAssVpxpsHUZ34q5pHdaaah/Vx9giMIDIua1zUFy2q4Zlbqil4VW6oCwPzIrtsa2LfI+eHxnWuLuPaRkTT0K1sdsPhk6jCVVMMlL1CTZXwGJJa8vjt0PncHqpbOetJG6AQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=DdFJWWfy; arc=none smtp.client-ip=95.215.58.189 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="DdFJWWfy" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1758872796; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=21M1f7vKrZ6Lv4atYZfvushCM3TQJZysEfiNB2lTWpk=; b=DdFJWWfyIyZ4l8oWpKRwgq0I38LKSjqfjA50zNAAooc4TAlLUC2NSJcUa7D/BlbvrebcSq HTLCz5hgJRLDc79jwVZ2YQTc8uB9n+XhoWbXtKxa5/SopwCLxfA1e0QhwzjpN5553gObCQ /CnqySrWXyhTPs9J3Xugmcbt9vM0mtA= From: Youling Tang To: Chris Mason , Josef Bacik , David Sterba Cc: linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, youling.tang@linux.dev, Youling Tang Subject: [PATCH] btrfs: Add the nlink annotation in btrfs_inode_item Date: Fri, 26 Sep 2025 15:45:43 +0800 Message-ID: <20250926074543.585249-1-youling.tang@linux.dev> 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 X-Migadu-Flow: FLOW_OUT Content-Type: text/plain; charset="utf-8" From: Youling Tang When I created a directory, I found that its hard link count was 1 (unlike other file system phenomena, including the "." directory, which defaults to an initial count of 2). By analyzing the code, it is found that the nlink of the directory in btrfs has always been kept at 1, which is a deliberate design. Adding its comments can prevent it from being mistakenly regarded as a BUG. Signed-off-by: Youling Tang --- include/uapi/linux/btrfs_tree.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/uapi/linux/btrfs_tree.h b/include/uapi/linux/btrfs_tre= e.h index fc29d273845d..b4f7da90fd0e 100644 --- a/include/uapi/linux/btrfs_tree.h +++ b/include/uapi/linux/btrfs_tree.h @@ -876,6 +876,7 @@ struct btrfs_inode_item { __le64 size; __le64 nbytes; __le64 block_group; + /* nlink in directories is fixed at 1 */ __le32 nlink; __le32 uid; __le32 gid; --=20 2.43.0