Re: [PATCH 3/3] ovl: redirect on rename-dir
From: Konstantin Khlebnikov
Date: Mon Nov 07 2016 - 06:31:29 EST
On Mon, Nov 7, 2016 at 2:03 PM, Raphael Hertzog <hertzog@xxxxxxxxxx> wrote:
> 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)
Mixing flags from mount options, xattrs and emptiness of upper layer
doesn't make it simpler.
We have clear statement that options in /proc/mounts describes overlay
instance, let's keep feeding state in this way.
>> 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.
/etc/mke2fs.conf is used by mkfs.ext4 - state is saved in super-block
overlayfs have no persistent super-block.
>> 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.
Other application are already aware about overlay layout and use it.
We cannot enable by default new backward incompatible features.
Returning -EXDEV is a completely correct semantics for rename,
most applications employ broken assumptions about this syscall =)
>> 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.
> 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/