On Sat, 2016-05-14 at 21:21 -0500, Eric W. Biederman wrote: > James if you could see shiftfs with a different set of merits than > what to Djalal is doing I think that would be useful. As it would > allow everyone to concentrate on getting the bugs out of their > solutions. Just to reply to this specific point. Djalal's patches can't actually work for me because I use subtree based roots rather than whole fs roots ... it's mostly because I work with image directories, not the full mounted images themselves. For stuff I unpack into /home, I could see having /home on a separate directory and adding the vfs_shift_ flags. however, I'm not doing (and it would be really unsafe to do) that for / to get my images that unpack in /var/tmp (like the obs build roots). However, half the ugliness of the patch set is that it needs lower layer FS support because vfs_shift_ are mount flags in the superblock. If they were made subtree flags instead (so MNT_ flags), I think you could eliminate the need to modify any underlying filesystems and they would allow us to mark subtrees for shifting. the mount command would need modifying to add them (like it was for --shared and --private) so we'd need an additional --vfs-shift --ufs-shift to mark the subtree but then the series would work for bind mounting subtrees, which is what I need. And they would work for *any* filesystem without modification. This would probably be the better of both worlds because it will work for the docker case as well. James -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html