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=-0.6 required=3.0 tests=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 6BAD5C5ACD9 for ; Wed, 18 Mar 2020 16:06:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 390B620658 for ; Wed, 18 Mar 2020 16:06:06 +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="PmkHFgaj" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727127AbgCRQGD (ORCPT ); Wed, 18 Mar 2020 12:06:03 -0400 Received: from mail-il1-f196.google.com ([209.85.166.196]:46155 "EHLO mail-il1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726817AbgCRQGD (ORCPT ); Wed, 18 Mar 2020 12:06:03 -0400 Received: by mail-il1-f196.google.com with SMTP id e8so24121276ilc.13 for ; Wed, 18 Mar 2020 09:06:02 -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=Q+E6phefA0/UCxZU68Ee5CkdpY/LreXqfKusKthyp5I=; b=PmkHFgajk2/8VWOHdYUg8VCj1tVopeX6fqfrGgYm0sPb35e5EoxUjxowANbaw3zCwS wqDhItzeSSD2F4OzNelMLAyDUKSqRDkOzITlg+Hge+tWY5LhXczVM8GuM5pTiPEM5aFa ut6OlQnzTW2CXrIbgEnOI63xRs4UIkIGUhynA= 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=Q+E6phefA0/UCxZU68Ee5CkdpY/LreXqfKusKthyp5I=; b=nmdb+LfVyS3D0aD55JzYj/bwUn4KMlBHapCRbNzxzzowNrGsYbDLA06/jG4aIZ2vqV Po46W5eFN+244m896NHdaptdNnmL8HcMupUvGYY3Wp9svhiubCuGRopz44FgelV4MmYg DVnj7QXa/2bjh/uYMDI02dSvmBwPCQBDwrivu5hTSYMfMawmPEdEVObg1myvFo+E5fdP 8XcfR0qBobEX5LONbkXTpTDqKnwizIYw1efGzWBDRwqPdVJbZ5+V9WbH+og/U+8vaVSe otJAkghZ//wFG/Gh6bHkcMZtqBT6yMogdpP5Es0jZB/sOTo3f8v7c+HTm3Dsd09SQIpy bZsg== X-Gm-Message-State: ANhLgQ0tXoqJARwiJ6CgrIi/9kWpJw3hfDvwyvS7bVodlFtnpx602pJb eg/nsvA9GzzcNrOheZ5Ch/bF+2ehHfHZoPZVmgU3nw== X-Google-Smtp-Source: ADFU+vseuj9ZXYFeMbS3X+5vGmRRSiZoxImF5rzfLQFjQscZDtBKPWLdRkROYV3TZYIAEV5wBxQF2hmZ0LlipmXRNY0= X-Received: by 2002:a92:5d52:: with SMTP id r79mr4664957ilb.212.1584547562099; Wed, 18 Mar 2020 09:06:02 -0700 (PDT) MIME-Version: 1.0 References: <158454408854.2864823.5910520544515668590.stgit@warthog.procyon.org.uk> In-Reply-To: <158454408854.2864823.5910520544515668590.stgit@warthog.procyon.org.uk> From: Miklos Szeredi Date: Wed, 18 Mar 2020 17:05:50 +0100 Message-ID: Subject: Re: [PATCH 00/13] VFS: Filesystem information [ver #19] To: David Howells Cc: Linus Torvalds , Al Viro , Linux NFS list , Andreas Dilger , Anna Schumaker , "Theodore Ts'o" , Linux API , linux-ext4@vger.kernel.org, Trond Myklebust , Ian Kent , Miklos Szeredi , Christian Brauner , Jann Horn , "Darrick J. Wong" , Karel Zak , Jeff Layton , linux-fsdevel@vger.kernel.org, LSM , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Wed, Mar 18, 2020 at 4:08 PM David Howells wrote: > ============================ > WHY NOT USE PROCFS OR SYSFS? > ============================ > > Why is it better to go with a new system call rather than adding more magic > stuff to /proc or /sysfs for each superblock object and each mount object? > > (1) It can be targetted. It makes it easy to query directly by path. > procfs and sysfs cannot do this easily. > > (2) It's more efficient as we can return specific binary data rather than > making huge text dumps. Granted, sysfs and procfs could present the > same data, though as lots of little files which have to be > individually opened, read, closed and parsed. Asked this a number of times, but you haven't answered yet: what application would require such a high efficiency? Nobody's suggesting we move stat(2) to proc interfaces, and AFAIK nobody suggested we move /proc/PID/* to a binary syscall interface. Each one has its place, and I strongly feel that mount info belongs in the latter category. Feel free to prove the opposite. > (3) We wouldn't have the overhead of open and close (even adding a > self-contained readfile() syscall has to do that internally Busted: add f_op->readfile() and be done with all that. For example DEFINE_SHOW_ATTRIBUTE() could be trivially moved to that interface. We could optimize existing proc, sys, etc. interfaces, but it's not been an issue, apparently. > > (4) Opening a file in procfs or sysfs has a pathwalk overhead for each > file accessed. We can use an integer attribute ID instead (yes, this > is similar to ioctl) - but could also use a string ID if that is > preferred. > > (5) Can easily query cross-namespace if, say, a container manager process > is given an fs_context that hasn't yet been mounted into a namespace - > or hasn't even been fully created yet. Works with my patch. > (6) Don't have to create/delete a bunch of sysfs/procfs nodes each time a > mount happens or is removed - and since systemd makes much use of > mount namespaces and mount propagation, this will create a lot of > nodes. Not true. > The argument for doing this through procfs/sysfs/somemagicfs is that > someone using a shell can just query the magic files using ordinary text > tools, such as cat - and that has merit - but it doesn't solve the > query-by-pathname problem. > > The suggested way around the query-by-pathname problem is to open the > target file O_PATH and then look in a magic directory under procfs > corresponding to the fd number to see a set of attribute files[*] laid out. > Bash, however, can't open by O_PATH or O_NOFOLLOW as things stand... Bash doesn't have fsinfo(2) either, so that's not really a good argument. Implementing a utility to show mount attribute(s) by path is trivial for the file based interface, while it would need to be updated for each extension of fsinfo(2). Same goes for libc, language bindings, etc. Thanks, Miklos