From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) (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 EA0623C277B for ; Wed, 22 Apr 2026 11:40:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776858003; cv=none; b=E9eQnNazGUEHy3u0CTDUI+dTaU1b3gllQsriIrEzqYb+pxl7W9c5RdvNnL62tXeFWLlZQ5HweoI+mx58l4QNtHdt8+zcIt4REiF9gSwIl4zit+THClTsooHAyH3jOEOizJfUsnuPu2XkDt+u+dT6KyStjX+NBSF9HOkFmO14VPE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776858003; c=relaxed/simple; bh=7jSkwPHB1rmAue0G4ep5X5x0tFp0MCnjlBuXF0HrV68=; h=Message-ID:Date:MIME-Version:From:Subject:To:Cc:References: In-Reply-To:Content-Type; b=rG2ZplUFfkZ5EpKVsk8/oucc2SPxAagyIiB3rJJcHi7IgKkunXvNMOT6ALEtw9s8Mfz+4ip8jdA+jynl/RncIy2lBGnJ1yPkhRm1AHFzBLJLCXtgkmnt/1vA/Q5nkxanENFpIm43HS6Lffu3EWQX3sNgG0q6EVP3m9R5kENfa64= 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=ll9mgn/J; arc=none smtp.client-ip=209.85.210.181 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="ll9mgn/J" Received: by mail-pf1-f181.google.com with SMTP id d2e1a72fcca58-82fcd0aa2dbso889822b3a.0 for ; Wed, 22 Apr 2026 04:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776858001; x=1777462801; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=MUHkTSAzkxq/Om8+jSsUbp1RMELRmuD0B/+VrfsdgxU=; b=ll9mgn/JnyYFNKhpAt/qyIgH1H+6MCuZuRMt6NoafZGs++QWkmwE9ELntcK6j2aZrs bjQDiQFaXB2pDrlBOV1aoPlpvtUlnweGGbZMAF9Q7qAo54WB+4r87Df9qK0m/MFglUBd BHMCkiou5z1IwPYX5t+7wdQ6N9NGl5PX0SBC+LSXK8JwUi9vyLk0h5QApWvWmE1B/ym0 SCtz+viyfmXeVbo/hLcsa8mfFKnC4LHSM4xJtetEzCH1GXbOMkQiH1fScUiEa/qYmSFM gZv5DV9WtfS5UBKC+jofPgs7h43TRT0mP/GxTto7wBYsxzUMpgxu2N0ZTl+YyPksLurO u+Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776858001; x=1777462801; h=content-transfer-encoding:in-reply-to:content-language:references :cc: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=MUHkTSAzkxq/Om8+jSsUbp1RMELRmuD0B/+VrfsdgxU=; b=TCV9ZPXgMVykLRN5te6+FZvZdH2m349onmNGUiH3NnFJztOpxDIDYih5eP261KqGmi o/FOVZf45Qh5sOmsjSYHX7lm0MS6WOADxgDxZ+9b7JpQWmKuH4lUElzfViGifHeGjoTC 2lriLmAJGiiV2p7v/UQ94rmQXxb0GtUXYFxATBKIbshClWdli5GezsoykUhAd2+0Ix5M hgiOgr3UIf5XZBVWa9CswZ+pnlAb7naWHANfR1CcopRLwdDGLcgFjnKd6jrc5Lf0x/EH hYgETRIdatALDM0qa851KTR+BoKghg2IITDJnU+XMEFGaOockaFzXWE0vEEIYhrMXH93 wohA== X-Forwarded-Encrypted: i=1; AFNElJ/oT4JMrRS4zw7Du3AsCkmoIYG8Uhxg3CjZRSAetwRpxmGig7Jtrc/bQob42ri5W9NK3PnShsu6DqNjpQ==@vger.kernel.org X-Gm-Message-State: AOJu0YwvbQ7PHtYMpTQMDZKHYCSZ+KkdmPz561cf/FeQXspq27++VEQ1 1CaSIuVUNNBSPAPNYTcw7VfLOnaajuSFrZaB9LHM0g7WwxprxdXeWtWl X-Gm-Gg: AeBDietHeqrub4jM/hl61ZXYI+JGDJB2IeRAYyXeH6oM0EEAUH0h75fyPvFPlDNxLvP USXUu2IGbOrcHj7DQ3kWsxyxxeBg9lXs6FpbZK1n8IRFOKk5A4+90Q6aB63n/BWTWcqd2IWcBxM 9kG7cB71qBtR1xgdmG+0tmuDxj6TQDNAc8+TPcEio6DAPRtapMPgd1R++ly4gyh2QTKdcDz9InY LLaLv3qDlWZKnq0s4cgblOFnI4aZLTcsdh7ihpUIja5aVrhw4Zxb0TeGreduutHDiN9bSB+HsO7 jlasLTFjn5tNWAjzJ8eORINhzbpv58FVkmamU8/jV87Ybyknc0UJky97flgl/7oSVLDQb51GqFJ tYoMrbhGKf+9euPE7paS0G1+DfnMwhmGsWzOjUFHO+a5lRQmOr+c2pT7O5VN6i/naRK9yPNH+2u GoSyVp6AkctTHD7Y9yWdIZWnzg1K36hy6vPCLOcw== X-Received: by 2002:a05:6a00:984:b0:82f:2985:2094 with SMTP id d2e1a72fcca58-82f8b554ebemr18415296b3a.30.1776858001175; Wed, 22 Apr 2026 04:40:01 -0700 (PDT) Received: from [192.168.50.90] ([116.87.14.48]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-82f8ec0092bsm18335315b3a.50.2026.04.22.04.39.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Apr 2026 04:40:00 -0700 (PDT) Message-ID: Date: Wed, 22 Apr 2026 19:39:57 +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: Christoph Hellwig Cc: Theodore Tso , "Darrick J. Wong" , linux-ext4@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-xfs@vger.kernel.org, Anand Jain , dsterba@suse.com References: <20260323041624.GA11453@mac.lan> <5bda3d00-df35-4ea1-b313-2fef6e5c5682@gmail.com> <20260407144709.GA81690@macsyma-wired.lan> <3c9e478a-42ef-446f-a8cc-1b4ac970d2ef@gmail.com> <20260409041035.GC99725@macsyma-wired.lan> <22cfbf8d-af9b-462e-b240-67a1de24764f@gmail.com> <20260409131238.GC18443@macsyma-wired.lan> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit >> It seems we've reached the functional limits of f_fsid. >> If we want to solve this properly for Overlayfs, NFS handles, or a >> complex system monitoring..etc, we need a new identifier let's call >> it f_fsid_v2, that meets the following requirements: >> >> System-wide Uniqueness: Must distinguish between cloned filesystems. >> >> Persistence: Must remain consistent across reboots/HW re-enumeration. My mistake- this should be: Consistency: Must remain consistent across reboots/HW re-enumeration. >> >> Non-On-Disk: Must not be stored on-disk. > > The third requirement doesn't make much sense to me. If it is > persistent it. or something it can be derived from must be stored > on-disk. I hope it make sense now with "Persistence" replaced by "Consistency" for the 2nd requirement (above). >> One possible implementation for f_fsid_v2 could be: >> >> f_fsid_v2 = hash(s_uuid, block_device_serial, [subvol_id]) >> >> For pseudo block devices (virtio-blk, loop, nbd, brd,..), >> the serial could be derived recursively: >> >> serial_number = hash(backing_file.f_fsid_v2, backing_file.ino) > > What i the point in this? All of this seems to be better served > by s_uuid. The goal is to fix duplicate f_fsid issues in cloned filesystems by creating a unique, reboot-consistent ID. This allows the source and clone to remain identical (sharing same uuid) while still being individually identifiable. >> Note on Hardware Serials: >> Standard storage protocols (T10, NVMe, SAS) mandate unique, >> persistent serials per LUN. While I've seen T10 protocol >> violations during my time authoring Solaris HBA drivers, I >> believe these outliers shouldn't dictate the design. > > No, T10 does not actually mandate unique identifiers, NVMe does, but the > implementations are often totally broken. Right. Newer SPC-3 (and above) compliant devices must support the Inquiry CDB EVPD flag and provide page 0x83 for identification, which is what we typically use for multipathing. These are globally unique. And, we can overlook legacy drives, as they've probably been past their EOSL for a while now. We can tweak the algorithm as follows: ID = hash(s_uuid, device_identifier_id, partition_start_lba, partition_end_lba, [subvol_id], [file.ino]) This is an ID which remains consistent across reboots while staying unique within the system, which we can use it for f_fsid. Thanks.