From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) (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 8E023242D70 for ; Mon, 23 Mar 2026 15:42:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774280521; cv=none; b=ovLATBovl5tyoW48t0bXnQmm89+1ygzON65FBnyjE00Fva66/PmCZqxy/iFEsgwb3n3fUhFHBCiXCniXHDCjXgG2IimOeAllP82OPJlmQ2XqUdWVl74p5OIcKZnLqUgt5rHsiXOwBLcvO7gcoOT1uVQ8jA0f3BvVnqPZAV9pJPw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774280521; c=relaxed/simple; bh=G0iEyskgYFiJJiPSQ4A29LWYf606VVmNVt75ke+W7JI=; h=Message-ID:Date:MIME-Version:From:Subject:To:References:Cc: In-Reply-To:Content-Type; b=WemzUBh1+P8HHsq4a6hrKJKnbkqCscN7DLAFb7nYC84yPFYugjCL3+acJy1fYhjlmg8ZKJatauyj1yU4B4D8QZsRKduca4QQ6hxX/IMHYPyDPRKD4t3cjXUk/hi8Cjh4ZBnqfRHhhrS0bTHrTaqGBu4BPIcOJw+U1dm25tSslqw= 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=YOAIrZas; arc=none smtp.client-ip=209.85.214.174 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="YOAIrZas" Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-2adff872068so13397455ad.1 for ; Mon, 23 Mar 2026 08:42:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1774280520; x=1774885320; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:cc:content-language :references:to:subject:from:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=YoImiZTZK9N2ji1T/Hu9es0UV7jPW/Nj0ifX24VqaCA=; b=YOAIrZasw2dFF8BiVnyWzRBiSEoUZpkroWlo/4nmXBLN40yHMA9vGZTYnwuiv5rSlO qQR1XxRu1dJdPm/JbDZR3aKpttrlXqNn1rnu8kUJFMlloEL+vQOHDazeKSKo1+l+PsqG 4X2akiIy9wC1hx8W6e7cFtEXPlswCfq6mgFZcfC/qlXLrc1R5t0QiJi5t5xas/4ol9K2 G85SMbG786gCmpTSVpB54BU9dH3gypEWC4lMZdtXSZ6kp9KV4dITyFFTa8mmcRWCctl3 MyJO9ivMNmEVvneOZ9Ijyn9eZDkYg5Zn2kaCEW2+fI0KTtp6zklv7F6yoIHm3CxMEN4m Sauw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774280520; x=1774885320; h=content-transfer-encoding:in-reply-to:cc:content-language :references:to:subject:from:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YoImiZTZK9N2ji1T/Hu9es0UV7jPW/Nj0ifX24VqaCA=; b=dVMbvywqVsBbl95P6U4zGi8VqyRSo6QDVbnhhUcYWjAqILHuXFW7D3pqPExD1WBpZx tDoF0wh4416mYyJxgruWVug4N6veg1k3/q7wPx9rbD/oVDvoQD5ShAZyz6rwZEKKK8kE c3/9bC7fix0flqVocHLix46uW6cpfUcRsBlBmkIrxOL1uX6nveg9og3yvpKUzIFvTCpM AG9fIUHs4bW0F+fevdJ6f0ALhP8zzzs71pjtWpO0tKfvOaZ331Hxm+s6VrW3THnLKna5 xvUFWxlo2gWyseoLzOvYFaa4nJ8OvN6Qdrd3zEO52DEMdXjsacNw0vHflr3CGml6A1Cu Xq1Q== X-Forwarded-Encrypted: i=1; AJvYcCV33cncpmyZeSD8g+f2x48SGuQpfx6MaDJ6zEPtEkFj7F0gfIvQzwAAWVFOnn7GjxL8JncrwOS8HuVE3Q==@vger.kernel.org X-Gm-Message-State: AOJu0YxPm2VLdQy/Jra4ny6t5fN2N4A4ath2gD6bwJ9nuEYoQBfRhr+1 /qvPhdSLUySEYeElb3MRDa814YF6t9tOHJdfCefak0iFw5whX2GrDW1D X-Gm-Gg: ATEYQzz9G4mXdUXgnrqUlm4KvMhYI+gDEH+txLsGsLKk8dqvbd6xgwpfQRmUnAmVuYQ irShdbpPDrQfguECIvtFRe83AO0cGTpkyZtMorAP4P1pl1UNAlcZOJoAYgiL+Syi7ZUX0fCCKKl dpKQ3wJZcgw+lYYUeUQ47jTt07xRet+Ta/B64yq9v4cJx1obcflL/TIoCa/aV4WyNTOjy72oOj3 CTZFYu3tiRiN4cRSXWIBApRFmYWL9yeKBineKnktDRkhAauuN3hbJR6GtPQfswj8OVX35CMvOFN i0Biqxn2CIsdEwXpJrArYfyLHxlMkyfXKG8lGHe7o6SCDGiyD3it3LUvY39UzsawJab+zRBSRXU C5mPTnHsJgIvxHVgdor470Y3GLAx5Xwohxhu33vj+4rPmmMddx1u8pV7gf0iwLs2iYK+hdKfp1p irdBI9CwBjHGz2ZuxVAmts8gqUB70= X-Received: by 2002:a17:902:ccd2:b0:2b0:5682:6973 with SMTP id d9443c01a7336-2b08273d0d4mr113011925ad.19.1774280519745; Mon, 23 Mar 2026 08:41:59 -0700 (PDT) Received: from [192.168.50.90] ([116.87.14.48]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b08354bcf0sm119018765ad.33.2026.03.23.08.41.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Mar 2026 08:41:59 -0700 (PDT) Message-ID: Date: Mon, 23 Mar 2026 23:41:55 +0800 Precedence: bulk X-Mailing-List: linux-btrfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Anand Jain Subject: Re: [PATCH v2 3/3] ext4: derive f_fsid from block device to avoid collisions To: Theodore Tso References: <33e8eb64c304a4d42b60f608c26497bf9a2e9e19.1774092915.git.asj@kernel.org> <20260323041624.GA11453@mac.lan> Content-Language: en-US Cc: linux-ext4@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-xfs@vger.kernel.org, Christoph Hellwig , Anand Jain In-Reply-To: <20260323041624.GA11453@mac.lan> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Thanks for the feedback. I'll try to address the points raised here and in your earlier email [1]. [1] https://lore.kernel.org/all/20260322203151.GA98947@mac.lan/ This work originally came out of a Btrfs issue where a cloned filesystem ended up using a dynamically generated, mount-time UUID for sb->s_uuid instead of the on-disk UUID. As a result, OverlayFS (with index enabled) started failing mount-recycle tests [2] for the cloned filesystem. [2] https://lore.kernel.org/lkml/20251014015707.129013-1-andrealmeid@igalia.com/ While looking into that problem, I also noticed that different filesystems derive f_fsid in inconsistent ways, and in practice many of them base it on dev_t. On the question of the 64-bit limit: although a 64-bit value is not globally unique in the way a 128-bit UUID is, f_fsid has historically been derived from dev_t. Since dev_t must be unique within a running kernel instance, 64 bits are enough to safely encode its effective ~32-bit dev_t without collisions. The number of concurrently addressable block devices is also bounded by the 12-bit major / 20-bit minor limits and /proc/sys/fs/mount-max. IMO, within a single boot, 64 bits should provide a collision-free identifier. I've also submitted new test cases that validate expectations around both sb->s_uuid and statfs::f_fsid here [3]. [3] https://lore.kernel.org/fstests/cover.1774090817.git.asj@kernel.org/ > As I observed in [1] this leads to collisions when for removable block > devices which can be used to mount different file systems. > > [1] https://lore.kernel.org/all/20260322203151.GA98947@mac.lan/ I agree. A straightforward f_fsid = f(dev_t) will collide if a removable device is swapped but ends up reusing the same dev_t. Theoretically, I see this can be reproduced with XFS, and with my current patchset on Ext4. That’s clearly a blocker, and I plan to revise, btw Btrfs does well for this test scenario. > And even as you've proposed to change > things, it's not consistent across file systems. In particular, your > proposed solution mixes s_uuid into btrfs-patched, but not > ext4-patched. Why? The discrepancy exists because Btrfs must distinguish subvolume mounts as separate logical entities. For Btrfs, the derivation requires f(s_uuid, root_id, dev_t) to ensure that two different subvolumes on the same device report distinct f_fsid values. For Ext4, a simpler f(s_uuid, dev_t) should suffice to ensure both cross-device uniqueness and persistent across media swaps. >> Place this change behind the new mount option "-o nouuid" for ABI >> compatibility. > > I *really* hate this mount option. It's not at all obvious what it > means for a system administrator who hasn't had the context of reading > the e-mail discussion on this subject. > > As I stated in [1], I think the f_fsid is a terrible interface that > was promulgated by history, and future usage should be strongly > discouraged, and the wise programmer won't use it because it has > significant compatibility issues. > > As such, my personal preference is that we not try to condition it on > a mount option, which in all likelihood almost no one will use, and > instead just change it so that we hash the file system's UUID and > block device number together and use that for ext4's f_fsid. The decision to gate this behind a mount option followed feedback from Christoph Hellwig. The concern is binary compatibility: applications that manually derive an ID based on existing behavior might break if the kernel changes its derivation logic. I agree that -o nouuid is a poor name. If we must keep the mount option for ABI stability, I am open to better nomenclature. If we agree that f_fsid is already a problematic interface and should simply be fixed without any special options for example by always hashing the filesystem UUID together with the block device number for Ext4, that would be my preference. Thanks, Anand