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 B308EC4BA3D for ; Thu, 27 Feb 2020 09:36:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8B43F24672 for ; Thu, 27 Feb 2020 09:36:50 +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="nMST/l5y" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728725AbgB0Jgu (ORCPT ); Thu, 27 Feb 2020 04:36:50 -0500 Received: from mail-io1-f67.google.com ([209.85.166.67]:33277 "EHLO mail-io1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728666AbgB0Jgt (ORCPT ); Thu, 27 Feb 2020 04:36:49 -0500 Received: by mail-io1-f67.google.com with SMTP id z8so2496367ioh.0 for ; Thu, 27 Feb 2020 01:36:49 -0800 (PST) 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=TSFAYumXnIb4mNx6pb9jSCJtikoAu1fiU5AFDR41HiM=; b=nMST/l5yp4EsOlkQkjz+oyXVo6tR4nbd5GbUbI5x84hWOMcXm3M7y8DV6kt66nn7b7 GIlsjbkbx3vQijL/6+LHbt8H5ZHfFqOOXohYBjwIMdjJnBLoeC35oZ4Yl225QYdACe5/ kVd9f5v/M5gtnQTRoS4CTQDPAYtlf8yBp6HVk= 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=TSFAYumXnIb4mNx6pb9jSCJtikoAu1fiU5AFDR41HiM=; b=H8CUjuUOCWVYLwqWG0Rv/yFqwj0SvX9I1NL52Udd4fd4aT++lLNCUhH0gzOnzxRrke yRoBtcomO0cEVCs0Yv497jL9jYOg+q5I7iTNA1t+pIZi71p12k2pFv6xB3tetmeZMB4/ Y/21ggCP70uHIpT3Erm+HNg9HHP4cyHzXXAZWn0A7zJreGFYaHEDMn1krK5LG1uhjAMx +wyFhZdtijJcz1fCvXjKhHBcqpyT704rH3I1WRGErq+1jrCle//hkhCBhNBmI4ZRiWqp yGOcUrwQWqf9A4GrUQyEPAndf+aOgoNQ4RGuFLHVytxTclHpDMpuW0EPKhLO7k7fL2O2 ZkJQ== X-Gm-Message-State: APjAAAWaEuMTvkS5SMs268kwvM0C0Fiiy9t6fiKhLB+7PV6FvZv3+K07 m+aE7EySIu6LUftXQvyw/5Kf8bnSlUH6hMzVqKogRA== X-Google-Smtp-Source: APXvYqw5v6WxqDR1yb3LDbMMK6C7QWK8wr5eU3zXIVtb+M97KWiW/29yrC6ghVKgpIwZqN9mr5PMGU2nHAVDTWUTGO8= X-Received: by 2002:a05:6602:382:: with SMTP id f2mr3597157iov.174.1582796209051; Thu, 27 Feb 2020 01:36:49 -0800 (PST) MIME-Version: 1.0 References: <158230810644.2185128.16726948836367716086.stgit@warthog.procyon.org.uk> <1582316494.3376.45.camel@HansenPartnership.com> <1582556135.3384.4.camel@HansenPartnership.com> <1582644535.3361.8.camel@HansenPartnership.com> <1c8db4e2b707f958316941d8edd2073ee7e7b22c.camel@themaw.net> In-Reply-To: <1c8db4e2b707f958316941d8edd2073ee7e7b22c.camel@themaw.net> From: Miklos Szeredi Date: Thu, 27 Feb 2020 10:36:38 +0100 Message-ID: Subject: Re: [PATCH 00/17] VFS: Filesystem information and notifications [ver #17] To: Ian Kent Cc: Miklos Szeredi , James Bottomley , Steven Whitehouse , David Howells , viro , Christian Brauner , Jann Horn , "Darrick J. Wong" , Linux API , linux-fsdevel , lkml Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Thu, Feb 27, 2020 at 6:06 AM Ian Kent wrote: > At the least the question of "do we need a highly efficient way > to query the superblock parameters all at once" needs to be > extended to include mount table enumeration as well as getting > the info. > > But this is just me thinking about mount table handling and the > quite significant problem we now have with user space scanning > the proc mount tables to get this information. Right. So the problem is that currently autofs needs to rescan the proc mount table on every change. The solution to that is to - add a notification mechanism - and a way to selectively query mount/superblock information right? For the notification we have uevents in sysfs, which also supplies the changed parameters. Taking aside namespace issues and addressing mounts would this work for autofs? Thanks, Miklos