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 D0E68C433E5 for ; Thu, 13 Aug 2020 10:36:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AD4BB206A4 for ; Thu, 13 Aug 2020 10:36:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="YjVN439y" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726596AbgHMKg6 (ORCPT ); Thu, 13 Aug 2020 06:36:58 -0400 Received: from us-smtp-1.mimecast.com ([207.211.31.81]:33641 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726252AbgHMKg5 (ORCPT ); Thu, 13 Aug 2020 06:36:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1597315015; 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=nHTuFVTalfQfPA2SgrXd36xvN0GI3IA7pVeXYZFZfuE=; b=YjVN439ywW+xeseIOdy7uo7XDhoznvbxmO6YF9QAe+czVHGS2K/iMP7E0lb8uOqGyRFDiE 589VYv5VonE03yhr2yPN2syUbqGzAPoqu8G3kxlutbzQqs+AOdH/4TfiGuBBYK4+56DiuA 1t+zWLZH/pvPSaOBM5zi2MR29w0he3U= 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-213-BabCGu27OAmcOQkv6mZDEg-1; Thu, 13 Aug 2020 06:36:52 -0400 X-MC-Unique: BabCGu27OAmcOQkv6mZDEg-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 28E848BF8A4; Thu, 13 Aug 2020 10:36:41 +0000 (UTC) Received: from ws.net.home (unknown [10.40.193.69]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5A4CF6760B; Thu, 13 Aug 2020 10:36:37 +0000 (UTC) Date: Thu, 13 Aug 2020 12:36:34 +0200 From: Karel Zak To: Linus Torvalds Cc: Steven Whitehouse , David Howells , Miklos Szeredi , linux-fsdevel , 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 Message-ID: <20200813103634.ey2xxwgbn3e4lhdr@ws.net.home> References: <20200811135419.GA1263716@miu.piliscsaba.redhat.com> <52483.1597190733@warthog.procyon.org.uk> <066f9aaf-ee97-46db-022f-5d007f9e6edb@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.14 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 12, 2020 at 12:50:28PM -0700, Linus Torvalds wrote: > Convince me otherwise. AGAIN. This is the exact same issue I had with > the notification queues that I really wanted actual use-cases for, and > feedback from actual outside users. I thought (in last 10 years) we all agree that /proc/self/mountinfo is the expensive, ineffective and fragile way how to deliver information to userspace. We have systems with thousands of mountpoints and compose mountinfo in kernel and again parse it in userspace takes time and it's strange if you need info about just one mountpoint. Unfortunately, the same systems modify the huge mount table extremely often, because it starts/stops large number of containers and every container means a mount operation(s). In this crazy environment, we have userspace tools like systemd or udisk which react to VFS changes and there is no elegant way how to get details about a modified mount node from kernel. And of course we already have negative feedback from users who maintain large systems -- mountinfo returns inconsistent data if you read it by more read() calls (hopefully fixed by recent Miklos' mountinfo cursors); system is pretty busy to compose+parse mountinfo, etc. > I really think this is engineering for its own sake, rather than > responding to actual user concerns. We're too old and too lazy for "engineering for its own sake" :-) there is pressure from users ... Maybe David's fsinfo() sucks, but it does not mean that /proc/self/mountinfo is something cool. Right? We have to dig deep grave for /proc/self/mountinfo ... Karel -- Karel Zak http://karelzak.blogspot.com