On Wed, Oct 26, 2016 at 2:12 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > On Tue, Oct 25, 2016 at 1:57 PM, Raphael Hertzog <hertzog@xxxxxxxxxx> wrote: > >> Do you plan to make it the default in the future when it has been >> available for a while? >> >> Barring any regression introduced by your patch, it seems that the feature >> is best available by default since it allows legitimate operations to >> succeed that are otherwise refused. I understand that it makes it >> impossible to mount the overlay filesystem with an older kernel but is >> that problem more widespread than the one we're fixing here? On my side, >> overlayfs is only used in scenarios where the kernel is always the same >> (or newer compared to what created the initial filesystem). > > I think it would be safe to make it the default if upperdir is empty. > Nonempty implies that it was created with old kernel (or it was > crafted by hand). But there should be a way to explicitly turn it > off; either because of the need for backward compatibility or because > the old format is simply easier to work with for humans. > > How about: > > - 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. 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. 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. 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. -- Konstantin -- 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
