On Sun, 15 Aug 2021 09:39:08 +0200 Goffredo Baroncelli <kreijack@xxxxxxxxx> wrote: > I am sure that it was discussed already but I was unable to find any track > of this discussion. But if the problem is the collision between the inode > number of different subvolume in the nfd export, is it simpler if the export > is truncated to the subvolume boundary ? It would be more coherent with the > current behavior of vfs+nfsd. See this bugreport thread which started it all: https://www.spinics.net/lists/linux-btrfs/msg111172.html In there the reporting user replied that it is strongly not feasible for them to export each individual snapshot. > In fact in btrfs a subvolume is a complete filesystem, with an "own > synthetic" device. We could like or not this solution, but this solution is > the more aligned to the unix standard, where for each filesystem there is a > pair (device, inode-set). NFS (by default) avoids to cross the boundary > between the filesystems. So why in BTRFS this should be different ? >From the user point of view subvolumes are basically directories; that they are "complete filesystems"* is merely a low-level implementation detail. * well except they are not, as you cannot 'dd' a subvolume to another blockdevice. > Why don't rename "ino_uniquifier" as "ino_and_subvolume" and leave to the > filesystem the work to combine the inode and the subvolume-id ? > > I am worried that the logic is split between the filesystem, which > synthesizes the ino_uniquifier, and to NFS which combine to the inode. I am > thinking that this combination is filesystem specific; for BTRFS is a simple > xor but for other filesystem may be a more complex operation, so leaving an > half in the filesystem and another half to the NFS seems to not optimal if > other filesystem needs to use ino_uniquifier. I wondered a bit myself, what are the downsides of just doing the uniquefication inside Btrfs, not leaving that to NFSD? I mean not even adding the extra stat field, just return the inode itself with that already applied. Surely cannot be any worse collision-wise, than different subvolumes straight up having the same inode numbers as right now? Or is it a performance concern, always doing more work, for something which only NFSD has needed so far. -- With respect, Roman
