From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C856FC433E0 for ; Tue, 11 Aug 2020 19:39:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A7AAE206B2 for ; Tue, 11 Aug 2020 19:39:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726621AbgHKTjV (ORCPT ); Tue, 11 Aug 2020 15:39:21 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:53672 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726274AbgHKTjU (ORCPT ); Tue, 11 Aug 2020 15:39:20 -0400 Received: from ip5f5af08c.dynamic.kabel-deutschland.de ([95.90.240.140] helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1k5a7A-0001Ts-UI; Tue, 11 Aug 2020 19:39:17 +0000 Date: Tue, 11 Aug 2020 21:39:16 +0200 From: Christian Brauner To: Linus Torvalds Cc: Miklos Szeredi , linux-fsdevel , David Howells , Al Viro , Karel Zak , Jeff Layton , Miklos Szeredi , Nicolas Dichtel , Christian Brauner , Lennart Poettering , Linux API , Ian Kent , LSM , Linux Kernel Mailing List Subject: Re: file metadata via fs API (was: [GIT PULL] Filesystem Information) Message-ID: <20200811193916.zcwebstmbyvushau@wittgenstein> References: <1842689.1596468469@warthog.procyon.org.uk> <1845353.1596469795@warthog.procyon.org.uk> <20200811135419.GA1263716@miu.piliscsaba.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 11, 2020 at 09:05:22AM -0700, Linus Torvalds wrote: > On Tue, Aug 11, 2020 at 8:30 AM Miklos Szeredi wrote: > > > > What's the disadvantage of doing it with a single lookup WITH an enabling flag? > > > > It's definitely not going to break anything, so no backward > > compatibility issues whatsoever. > > No backwards compatibility issues for existing programs, no. > > But your suggestion is fundamentally ambiguous, and you most > definitely *can* hit that if people start using this in new programs. > > Where does that "unified" pathname come from? It will be generated > from "base filename + metadata name" in user space, and > > (a) the base filename might have double or triple slashes in it for > whatever reasons. > > This is not some "made-up gotcha" thing - I see double slashes *all* > the time when we have things like Makefiles doing > > srctree=../../src/ > > and then people do "$(srctree)/". If you haven't seen that kind of > pattern where the pathname has two (or sometimes more!) slashes in the > middle, you've led a very sheltered life. > > (b) even if the new user space were to think about that, and remove > those (hah! when have you ever seen user space do that?), as Al > mentioned, the user *filesystem* might have pathnames with double > slashes as part of symlinks. > > So now we'd have to make sure that when we traverse symlinks, that > O_ALT gets cleared. Which means that it's not a unified namespace > after all, because you can't make symlinks point to metadata. > > Or we'd retroactively change the semantics of a symlink, and that _is_ > a backwards compatibility issue. Not with old software, no, but it > changes the meaning of old symlinks! > > So no, I don't think a unified namespace ends up working. > > And I say that as somebody who actually loves the concept. Ask Al: I > have a few times pushed for "let's allow directory behavior on regular > files", so that you could do things like a tar-filesystem, and access > the contents of a tar-file by just doing > > cat my-file.tar/inside/the/archive.c > > or similar. > > Al has convinced me it's a horrible idea (and there you have a > non-ambiguous marker: the slash at the end of a pathname that > otherwise looks and acts as a non-directory) > Putting my kernel hat down, putting my userspace hat on. I'm looking at this from a potential user of this interface. I'm not a huge fan of the metadata fd approach I'd much rather have a dedicated system call rather than opening a side-channel metadata fd that I can read binary data from. Maybe I'm alone in this but I was under the impression that other users including Ian, Lennart, and Karel have said on-list in some form that they would prefer this approach. There are even patches for systemd and libmount, I thought? But if we want to go down a completely different route then I'd prefer if this metadata fd with "special semantics" did not in any way alter the meaning of regular paths. This has the potential to cause a lot of churn for userspace. I think having to play concatenation games in shared libraries for mount information is a bad plan in addition to all the issues you raised here. Christian