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.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 521D3C433E0 for ; Wed, 12 Aug 2020 10:14:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2F62D20781 for ; Wed, 12 Aug 2020 10:14:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Isi6oYcu" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727931AbgHLKOW (ORCPT ); Wed, 12 Aug 2020 06:14:22 -0400 Received: from us-smtp-2.mimecast.com ([205.139.110.61]:52664 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727112AbgHLKOV (ORCPT ); Wed, 12 Aug 2020 06:14:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1597227260; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xlMaPj1QKypnrQ0JYf3BSvOZztYvxS9nKRk9zqeHA7Y=; b=Isi6oYcuaQL/N5QcBPC06FeukL+0Z42GTgP/TBPHqA3thEmAptzRQn4XOwuyRX7mXH4eyo ehyjI5ECuIBCj6SvgDZomHldUAJFyhivKGdPGoVGJDBgrg5mgWmb4/KCrOTfwaidESwh09 mbGMPqyhlQFJcSurNHcIOKiOG+HzUlo= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-50-nnbUiC46N7C0aUmdRLKZbg-1; Wed, 12 Aug 2020 06:14:16 -0400 X-MC-Unique: nnbUiC46N7C0aUmdRLKZbg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 580991DE0; Wed, 12 Aug 2020 10:14:14 +0000 (UTC) Received: from ws.net.home (unknown [10.40.193.69]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B7C6B60C84; Wed, 12 Aug 2020 10:14:08 +0000 (UTC) Date: Wed, 12 Aug 2020 12:14:05 +0200 From: Karel Zak To: Linus Torvalds Cc: Miklos Szeredi , linux-fsdevel , David Howells , Al Viro , 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: <20200812101405.brquf7xxt2q22dd3@ws.net.home> 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=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 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 08:20:24AM -0700, Linus Torvalds wrote: > IOW, if you do something more along the lines of > > fd = open(""foo/bar", O_PATH); > metadatafd = openat(fd, "metadataname", O_ALT); > > it might be workable. I have thought we want to replace mountinfo to reduce overhead. If I understand your idea than we will need openat()+read()+close() for each attribute? Sounds like a pretty expensive interface. The question is also how consistent results you get if you will read information about the same mountpoint by multiple openat()+read()+close() calls. For example, by fsinfo(FSINFO_ATTR_MOUNT_TOPOLOGY) you get all mountpoint propagation setting and relations by one syscall, with your idea you will read parent, slave and flags by multiple read() and without any lock. Sounds like you can get a mess if someone moves or reconfigure the mountpoint or so. openat(O_ALT) seems elegant at first glance, but it will be necessary to provide a richer (complex) answers by read() to reduce overhead and to make it more consistent for userspace. It would be also nice to avoid some strings formatting and separators like we use in the current mountinfo. I can imagine multiple values separated by binary header (like we already have for watch_notification, inotify, etc): fd = openat(fd, "mountinfo", O_ALT); sz = read(fd, buf, BUFSZ); p = buf; while (sz) { struct alt_metadata *alt = (struct alt_metadata *) p; char *varname = alt->name; char *data = alt->data; int len = alt->len; sz -= len; p += len; } Karel -- Karel Zak http://karelzak.blogspot.com