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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 63723C433DF for ; Fri, 21 Aug 2020 13:18:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3BDDB207DA for ; Fri, 21 Aug 2020 13:18:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=szeredi.hu header.i=@szeredi.hu header.b="NU0Mcks7" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728746AbgHUNSY (ORCPT ); Fri, 21 Aug 2020 09:18:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33264 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727879AbgHUNSQ (ORCPT ); Fri, 21 Aug 2020 09:18:16 -0400 Received: from mail-ej1-x642.google.com (mail-ej1-x642.google.com [IPv6:2a00:1450:4864:20::642]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AFE47C061388 for ; Fri, 21 Aug 2020 06:18:14 -0700 (PDT) Received: by mail-ej1-x642.google.com with SMTP id g19so2219658ejc.9 for ; Fri, 21 Aug 2020 06:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9Ewq1eqi128tS/YtHe1Hdp0zK/pkzPgQy1G+gIZ86vk=; b=NU0Mcks72tdUBoRxTtGff5uEDLvy5q+04uOXS/JLA0SJHrmqdiP6jaEKtTvuhKsMgU lDfci7M0dnl3iqCTEKGFvbcUksW7F5hk3a91SmK7L3wWBKVmDsI9uP/rUVnGbwAsuDli PjLRD2P5KK/Uqcps5LzpvzKRXm9f6EQs1OMtc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9Ewq1eqi128tS/YtHe1Hdp0zK/pkzPgQy1G+gIZ86vk=; b=ZT5sZYBeFW8ACBOHj3EF7GwjjC+k3oWwYPPGcmsrWkcapL0InQ9yRJQItTYxMbkjex 6imoGVcDbukhC7WqKkoYET69n6Xcr3U89TaCJlV0ixeL3CVCkYq9NdOBh4mYek61n5aQ oYWVCnbX9UydOSJmky7hez5y8dllxKK5jXLQf/cZiW4nZxkLL09oG675kfHgj0Rge8Sz NaFPcB6QUlCpHsPysQiNZyeB9DoeWsqmLsTybN8XmX3nxT2gq/TXXRNmx4lmLGT34m7h VVzrHpUEzkz37ObuAFlPGqLYAzG3gdK81I9FEslqwr6xITPjM8sU8ubjXqeEPdcHqXmZ fAkg== X-Gm-Message-State: AOAM532hh6WoYIfDHjNw1QmlPLgO3cVxQUEYIA5BM1Ikzi2Eq25eM1VT wE+AMAJUSFgggzZeDvnXzyE2xWPwXESKGlPXJA+OVA== X-Google-Smtp-Source: ABdhPJx3TSW7MukTCaIid5gIoeUYGZLVJD0O+yZ7UPk2PTQBJG9g/hYdPVKEFV4KdfwhkvYvNtwBHnp0gKnoaXGmvjM= X-Received: by 2002:a17:906:b2d7:: with SMTP id cf23mr2811015ejb.113.1598015890534; Fri, 21 Aug 2020 06:18:10 -0700 (PDT) MIME-Version: 1.0 References: <1842689.1596468469@warthog.procyon.org.uk> <1845353.1596469795@warthog.procyon.org.uk> <20200811135419.GA1263716@miu.piliscsaba.redhat.com> <52483.1597190733@warthog.procyon.org.uk> <066f9aaf-ee97-46db-022f-5d007f9e6edb@redhat.com> <94f907f0-996e-0456-db8a-7823e2ef3d3f@redhat.com> In-Reply-To: From: Miklos Szeredi Date: Fri, 21 Aug 2020 15:17:59 +0200 Message-ID: Subject: Re: file metadata via fs API To: Linus Torvalds Cc: Steven Whitehouse , David Howells , linux-fsdevel , Al Viro , Karel Zak , Jeff Layton , Miklos Szeredi , Nicolas Dichtel , Christian Brauner , Lennart Poettering , Linux API , Ian Kent , LSM , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 18, 2020 at 10:53 PM Linus Torvalds wrote: > Basically, I think a rough rule of thumb can and should be: > > - stuff that the VFS knows about natively and fully is clearly pretty > mount-agnostic and generic, and can be represented in whatever > extended "struct statfs_x" directly. > > - anything that is variable-format and per-fs should be expressed in > the ASCII buffer > > Look at our fancy new fs_context - that's pretty much what it does > even inside the kernel. Sure, we have "binary" fields there for core > basic information ("struct dentry *root", but also things like flags > with MNT_NOSUID), but the configuration stuff is ASCII that the > filesystem can parse itself. > > Exactly because some things are very much specific to some > filesystems, not generic things. > > So we fundamentally already have a mix of "standard FS data" and > "filesystem-specific options", and it's already basically split that > way: binary flag fields for the generic stuff, and ASCII text for the > odd options. Okay. Something else: do we want a separate statmount(2) or is it okay to mix per-mount and per-sb attributes in the same syscall? /proc/mounts concatenates mount and sb options (since it copies the /etc/mtab format) /proc/self/mountinfo separates per-mount and per-sb data into different fields at least, but the fields themselves are mixed If we are introducing completely new interfaces, I think it would make sense to separate per-mount and per-sb attributes somehow. Atomicity arguments don't apply since they have separate locking. And we already have separate interfaces for configuring them... Thanks, Miklos