Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751257AbdIOIG3 (ORCPT ); Fri, 15 Sep 2017 04:06:29 -0400 Received: from mail-wr0-f196.google.com ([209.85.128.196]:35665 "EHLO mail-wr0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750865AbdIOIG1 (ORCPT ); Fri, 15 Sep 2017 04:06:27 -0400 X-Google-Smtp-Source: ADKCNb78ris1hHGKpJTBcYXl7Z//vztYTxdZCmP3bn6aE32BYEN6NIJ5llk0l5h+I52dPVQDK3xzSgyLvJAIUfT0AU0= MIME-Version: 1.0 X-Originating-IP: [194.176.227.33] In-Reply-To: <20170915073226.GC19278@veci.piliscsaba.szeredi.hu> References: <20170913140528.GA19278@veci.piliscsaba.szeredi.hu> <20170915073226.GC19278@veci.piliscsaba.szeredi.hu> From: Miklos Szeredi Date: Fri, 15 Sep 2017 10:06:24 +0200 Message-ID: Subject: Re: [GIT PULL] overlayfs update for 4.14 To: Linus Torvalds Cc: Al Viro , Linux Kernel Mailing List , linux-fsdevel , "linux-unionfs@vger.kernel.org" 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-Length: 1485 Lines: 30 On Fri, Sep 15, 2017 at 9:32 AM, Miklos Szeredi wrote: > On Thu, Sep 14, 2017 at 01:24:22PM -0700, Linus Torvalds wrote: > >> I just don't see any reason why those two "flags" arguments are separate. > > Fine. Here's a patch reverting the new flags and adding O_UPPER. And, btw. I also hate all the hacks we need to do in the VFS for the sake of overlayfs. It may actually end up all being removed and all the stacking moved to overlayfs; that's something I'd really like to look at. All of these hacks are there because overlayfs lets the open file be owned by the underlying filesystem, which is good for performance and results in simpler code in overlayfs, but may not actually be worth it. The whole overlayfs thing started because I was looking at the union mounts patches and seeing all the horrid vfs impacts and deciding, that surely some of this can go into a filesystem without major loss of performance. The first versions had really minimal vfs impact, but it turned out that that wasn't enough for a bunch of things to work correctly so d_real() evolved into the beast it is now. And we still have that issue with an fd opened for read-only and then one opened for write, resulting in a copy-up, modification, and the read-only fd still seeing the old data (union mounts had the same issue, BTW). So we need more hacks or some way to have a shared page cache that's breakable on copy up, which does not look trivial at all. Thanks, Miklos