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 :)