On 3/8/24 23:21, Boris Burkov wrote:
On Fri, Mar 08, 2024 at 09:42:56AM -0800, Christoph Hellwig wrote:
On Fri, Mar 08, 2024 at 09:32:54AM -0800, Boris Burkov wrote:
You remove/add the device in a way that results in a new bd_dev while
the filesystem is unmounted but btrfs is still caching the struct
btrfs_device. When we unmount a multi-device fs, we don't clear the
device cache, since we need it to remount with just one device name
later.
The mechanism I used for getting a different bd_dev was partitioning two
different devices in two different orders.
Ok, so we have a btrfs_device without a bdev around, which seems a bit
dangerous.
The 'btrfs_device' without a 'bdev' is just a hint for assembly in the
kernel, with validation occurring before 'bdev' is saved. Hence, it's
not clear how this could be dangerous.
Also relying on the dev_t for any kind of device identify
seems very dangerous.
dev_t is used as the device identity for the tempfsid feature. In the
case of two cloned single devices, the fsid + UUID + devid will match,
but they will differ by their dev_t. Therefore, the tempfsid feature
will mount them separately, assigning a temporary fsid (in memory only)
to one of the latter mounting device.
However, in the mount thread, if the dev_t also matches, it is
a subvol mount.
The actual use case for tempfsid is from the Steam Deck, where two
identical images created by disk dump are simultaneously mounted on
the host for validation. Ext4 supports cloned device mounting.
Aren't there per-device UUIDs or similar
identifiers that are actually reliabe and can be used instead of the
dev_t?
In this use case, when cloning the entire disk, the per-device UUID
also gets copied/duplicated. Using special clone tools to update
the device UUID will result in non-identical images, making them
unsuitable for the use case.
Thanks, Anand
I was led to believe this wasn't possible while still actually
implementing temp_fsid. But now that I think of it again, I am less sure.
You could imagine them having identical images except a device uuid and the
code being smart enough to handle that.
Maybe Anand can explain why that wouldn't work :)
