> Maybe what we really need is for a bunch of diverse filesystem > developers to get together and agree on some new common interface for > subvolume management, including coming up with some sort of definition > of what a subvolume "is". Neil, Seeing that LSF/MM is not expected to gather in the foreseen future, would you like to submit this as a topic for discussion in LPC Filesystem MC [1]? I know this is last minute, but we've just extended the CFP deadline until Sep 15 (MC is on Sep 21), so if you post a proposal, I think we will be able to fit this session in the final schedule. Granted, I don't know how many of the stakeholders plan to attend the LPC Filesystem MC, but at least Josef should be there ;) I do have one general question about the expected behavior - In his comment to the LWN article [2], Josef writes: "The st_dev thing is unfortunate, but again is the result of a lack of interfaces. Very early on we had problems with rsync wandering into snapshots and copying loads of stuff. Find as well would get tripped up. The way these tools figure out if they've wandered into another file system is if the st_dev is different..." If your plan goes through to export the main btrfs filesystem and subvolumes as a uniform st_dev namespace to the NFS client, what's to stop those old issues from remerging on NFS exported btrfs? IOW, the user experience you are trying to solve is inability of 'find' to traverse the unified btrfs namespace, but Josef's comment indicates that some users were explicitly unhappy from 'find' trying to traverse into subvolumes to begin with. So is there really a globally expected user experience? If not, then I really don't see how an nfs export option can be avoided. Thanks, Amir. [1] https://www.linuxplumbersconf.org/event/11/page/104-accepted-microconferences#cont-filesys [2] https://lwn.net/Articles/867509/
