Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752966AbcKGNmY (ORCPT ); Mon, 7 Nov 2016 08:42:24 -0500 Received: from mail.vm.ouaza.com ([212.83.178.2]:59008 "EHLO mail.vm.ouaza.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750998AbcKGNmT (ORCPT ); Mon, 7 Nov 2016 08:42:19 -0500 Date: Mon, 7 Nov 2016 14:42:15 +0100 From: Raphael Hertzog To: Konstantin Khlebnikov Cc: Miklos Szeredi , Miklos Szeredi , "linux-unionfs@vger.kernel.org" , Guillem Jover , linux-fsdevel , Linux Kernel Mailing List Subject: Re: [PATCH 3/3] ovl: redirect on rename-dir Message-ID: <20161107134215.2v5leafss2mamim5@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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20161014 (1.7.1) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2301 Lines: 55 On Mon, 07 Nov 2016, Konstantin Khlebnikov wrote: > > 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. It depends for whom. It does make it simpler for applications that just want overlayfs to work like other normal filesystems. > We have clear statement that options in /proc/mounts describes overlay > instance, let's keep feeding state in this way. Didn't you say above that xattrs provide flags too? > > 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. On the opposite, if we have to modify those applications to add a new mount option, then they will no longer work with older versions of overlayfs... so you move the complexity down to applications if they want to work with multiple kernel versions. There's no technical problem to enable a new backward incompatible feature. It's just that you don't want to do it in case the user wants to mount it again with an older kernel. So this is just policy. So what about a new mount option that defines a compatibility level? 0: initial feature set 1: with renamedir flag It would default to 1 but the user can set it to "0" to keep compatibility with older versions of overlayfs. In the future, as more backward incompatible changes are added, you add new levels and define the values of the various flags based on this setting. > Returning -EXDEV is a completely correct semantics for rename, > most applications employ broken assumptions about this syscall =) Maybe (I don't know what standards say), but then what matters is real-life. And in real-life, it's somewhat unexpected to get back -EXDEV when the rename() happens in the same directory (and has therefore no chance to cross any mount boundary). 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/