From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752747AbcKGLb2 (ORCPT ); Mon, 7 Nov 2016 06:31:28 -0500 Received: from mail-lf0-f68.google.com ([209.85.215.68]:34202 "EHLO mail-lf0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750912AbcKGLbX (ORCPT ); Mon, 7 Nov 2016 06:31:23 -0500 MIME-Version: 1.0 In-Reply-To: <20161107110319.7goz3ym3e6fu5lag@home.ouaza.com> References: <1477380887-21333-1-git-send-email-mszeredi@redhat.com> <1477380887-21333-4-git-send-email-mszeredi@redhat.com> <20161025115748.ydhkkp5cfcdnjzwn@home.ouaza.com> <20161107110319.7goz3ym3e6fu5lag@home.ouaza.com> From: Konstantin Khlebnikov Date: Mon, 7 Nov 2016 14:31:19 +0300 Message-ID: Subject: Re: [PATCH 3/3] ovl: redirect on rename-dir To: Raphael Hertzog Cc: Miklos Szeredi , Miklos Szeredi , "linux-unionfs@vger.kernel.org" , Guillem Jover , linux-fsdevel , Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id uA7BVVNH030677 On Mon, Nov 7, 2016 at 2:03 PM, Raphael Hertzog wrote: > 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) 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 inside filesystem. 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. > > 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/