Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Sounds like a kernel bug ... If it encounters another filesystem with the same ID, it should warn in dmesg and assign a null ID to one of them.


If it was this simple, they'd have done it, right? The idea is that filesystems have have the same UUID are actually part of the same filesystem. It's a long-lasting hm feature of Btrfs.

I think the actual dynamic filesystem discovery is in user space and kernel just gets a list of devices, so it should be even easier to change that.


That's fine but we can have a "device UUID" and "filesystem UUID" as separate constructs and then the complaint remains valid. It's okay for it to fail if you dd and try to mount (suboptimal, but okay), but it should never silently start breaking things while appearing to work.


Btrfs already has separate fsid and device id. Anyway, if you clone the device then those also stay the same, so I'm not sure what this would solve. How would the complete solution look like?

AFAIK the filesystem UUID, the device UUID, or both are sprinkled all around the filesystem, I suppose for reasons of identifying data belonging to the fs in case of fsck. According to my quick research device id cannot be changed. I suppose if it could be changed by some means, then btrfs rescue clear-uuid-tree could be used to fix the other uuids.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: