Hello, On Sun, 06 Nov 2016, Konstantin Khlebnikov wrote: > > - If upper is nonempty, then leave redirect feature alone except when > > mount option "-oredirect=on" is used to force enabling it. > > - If upper is empty, then enable redirect feature except when mount > > option "-oredirect=off" is used to force disabling it. > > I don't like this empty-nonempty upper logic. Why? (I don't have the feeling that your subsequent paragraphs answer this question... unless "overlayfs mounting is hard, let's complicate it even more" is your answer) > I think this feature should be off by default and be enabled > explicitly in mount option. > Available features could be listed in sysfs /sys/fs/overlay/..., like ext4 does. TTBOMK in ext4, they are set at mkfs time and the default feature set comes from /etc/mke2fs.conf. There's nothing like that for overlayfs. > Overlayfs mounting anyway is complicated operation. > User must know a lot about it and provide persistent state for each mount: > list layers in correct order, work and uppder directory on the same disk, etc. > Enabled features is a part of this state. A large part of the users are not direct overlayfs users, they use application (like schroot and live-build in my case) that rely on overlayfs to offer some user-modifiable throw-away chroots or some persistency on top of a read-only image. In both cases, the upper directory start empty. I find it highly disturbing to have to modify all those applications just to get the correct semantics to rename a directory. > Probably this could be solved in userspace tool "mount.overlay" - it could load > features and layers from config file or xattr and set required mount > options automatically. I'm all for having a better API to mount overlayfs, but I don't think blocking on the "redirect=on" by default is a good way to get this. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
