On Mon, Nov 06, 2023 at 09:13:19AM -0800, Christoph Hellwig wrote: > On Mon, Nov 06, 2023 at 02:47:16PM +0100, Christian Brauner wrote: > > Granted, an over-generalization but non in any way different from > > claiming that currently on one needs to know about btrfs subvolumes or > > that the proposed vfsmount solution will make it magically so that no > > one needs to care anymore. > > I don't think any one has claimed "no one" needs to care any more. What > the vfsmounts buy us that is that software that doesn't know and > should't know about btrfs subvolumes isn't silently broken. Software > that actually wants to do something fancy with them always need special > casing. Again, this is where I'm confused, because this doesn't change anything, we're still going to report st_dev as being different, which is what you hate. You pointed out above that user space thinks that different st_dev means different inode space. That is why Chris put the st_dev hack in, because rsync got confused, and this made it not confused. So we're actually doing exactly what user space wants, letting them know that they've wandered into a different inode ino space when they cross into a subvolume. But that's the crux of the problem, new subvolume == new inode number space. I'm not changing this. I don't think you want us to change this. We want to let user space who don't care to know about btrfs be able to operate cleanly. We have that with the st_dev hack. Changing to vfsmounts doesn't fix this. Userspace doesn't know it's wandered into a new directory, and in fact if you look at the rsync code they have a special python script you have to use if you want to exclude bind mounts, which is all the automount thing would accomplish. At this point I don't care, tell me what you want me to do so you'll stop complaining anytime we try to expose more btrfs specific information to user space and I'll do it. I'm tired of having this argument. You would have had auto mount patches in your inbox last week but it took me longer to get the new mount api conversion done than anticipated. But it doesn't appear to me there's agreement on the way forward. vfsmounts aren't going to do anything from what I can tell, but I could very well be missing some detail. And Christian doesn't seem to want that as a solution. Thanks, Josef
