On Mon, Jun 05, 2023 at 01:37:40PM +0200, Christian Brauner wrote: > Using a zero/special UUID would have made this usable for most > filesystems which allows userspace to more easily detect this. Using a > filesystem feature bit makes this a lot more fragmented between > filesystems. Not all file systems have feature bits. So I'd suggest that how this should be a file system specific implementation detail. If with a newer kernel, a file systems sets the UUID to a random value if it is all zeros when it is mounted should be relatively simple. However, there are some questions this brings up. What should the semantics be if a file system creates a file system-level snapshot --- should the UUID be refreshed? What if it is a block-level file system snapshot using LVM --- should the UUID be refreshed in that case? As I've been trying to point out, exactly what the semantics of a file system level UUID has never been well defined, and it's not clear what various subsystems are trying to *do* with the UUID. And given that what can happen with mount name spaces, bind mounts, etc., we should ask whether the assumptions they are making with respect to UUID is in fact something we should be encouraging. > But allowing to refuse being mounted on older kernels when the feature > bit is set and unknown can be quite useful. So this is also fine by me. This pretty much guarantees people won't use the feature for a while. People complain when a file system cann't be mounted. Using a feature bit is also very likely to mean that you won't be able to run an older fsck on that file system --- for what users would complain would be no good reason. And arguably, they would be right to complain. - Ted
