Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp756782pxa; Wed, 12 Aug 2020 12:37:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyZAKTDXkL2NJdTKuMpj35WPcXJQkTkBaA8JpHnMoemkvw0eS8T8/f6PiotRCoFMJASJ6Iw X-Received: by 2002:a17:906:1c0e:: with SMTP id k14mr1334805ejg.479.1597261054234; Wed, 12 Aug 2020 12:37:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597261054; cv=none; d=google.com; s=arc-20160816; b=p/NQRiNF/UzVA8HuAeeP/YNnxjA4tFb+PsdQmXPt4EUiHF+6fvVjW9w2Wv6MeJaSXL eNNV9mAyI9CnE7qI/T92urjY68FWG+5RISaYysE58YQ1/m4sw1mAiHnuIgrOph87RPXU 7+itSzrlwZju3DN/70r0923xf6W05M4xkR7oTp86Jc9Q+OENLYprG42j9Uwgts7kwdP8 GNN8MOATpqjA9AbPvvF8tcj1BggDDi/WYf+D8jZXvvn7m4vaOXqYnpcsOHJdGSVaFUC8 NCHrE9LgcO0beYciaeGsjaWGGZi45Ys4SNevU0PBY8emL5IMoIcRubA7rWBtWNl3MDrF 5GkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=9pSEoniKEkFNSbD4TVkJ4Otoswkj5jDImE3i/ppi82o=; b=VLjk/WZwNs/AkjDRx+3/VDH01QGA66Lxi+AYIceWHJUv93xTtfibvQLfgcb6fZlCFh aq4KM4LtqSDYfx5sRbesbVpxuTx6dRUj+Q5q7M27q2ZiNeHB5pHhvh8bKqXqThPgaxMx sSrhYyrmU17UUfgJNSJKbsSLNiCcigsA+r+ammSG6hWPfpBBH70YZtoNC+c5sr+K2Icu KdsleWP86+llFeVpsHRgRG+wW+PXXH+qWDb1jfVOQNI1L9mu0LifMBbhan6Li//8BRfU //Fli2ly8h/2Sa7CA0//pDmt8YPcvNy0mDj87pW62NkGUox7cIo4NOGW3fBu+oroiX8A YPfA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=TAMILBsr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bi9si2445244edb.366.2020.08.12.12.37.11; Wed, 12 Aug 2020 12:37:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=TAMILBsr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726698AbgHLTe0 (ORCPT + 99 others); Wed, 12 Aug 2020 15:34:26 -0400 Received: from us-smtp-2.mimecast.com ([205.139.110.61]:52359 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726567AbgHLTe0 (ORCPT ); Wed, 12 Aug 2020 15:34:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1597260864; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9pSEoniKEkFNSbD4TVkJ4Otoswkj5jDImE3i/ppi82o=; b=TAMILBsrqXIGZSvSbutFexYOkO91UTG1s8g8GpQ/iaK2oaHiGsxWqj7R9QXYbFlQ/3uZoo 4/xaIYIErSSXflJ23de1ZXLTbfI86aiavW0TlaZBW8YamUnNEh9Mj662CpFRlI8vvUbwK8 UBwSTnPiMQRk99XNiEaWKgsCqVD6H7s= 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-394-PsWf2ViBP-2ePLGug1Gcog-1; Wed, 12 Aug 2020 15:34:23 -0400 X-MC-Unique: PsWf2ViBP-2ePLGug1Gcog-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B39E61902EB3; Wed, 12 Aug 2020 19:34:20 +0000 (UTC) Received: from fogou.chygwyn.com (unknown [10.33.36.12]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 239A3100AE52; Wed, 12 Aug 2020 19:34:13 +0000 (UTC) Subject: Re: file metadata via fs API To: Linus Torvalds , David Howells Cc: Miklos Szeredi , 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 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> From: Steven Whitehouse Message-ID: <066f9aaf-ee97-46db-022f-5d007f9e6edb@redhat.com> Date: Wed, 12 Aug 2020 20:34:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 12/08/2020 19:18, Linus Torvalds wrote: > On Tue, Aug 11, 2020 at 5:05 PM David Howells wrote: >> Well, the start of it was my proposal of an fsinfo() system call. > Ugh. Ok, it's that thing. > > This all seems *WAY* over-designed - both your fsinfo and Miklos' version. > > What's wrong with fstatfs()? All the extra magic metadata seems to not > really be anything people really care about. > > What people are actually asking for seems to be some unique mount ID, > and we have 16 bytes of spare information in 'struct statfs64'. > > All the other fancy fsinfo stuff seems to be "just because", and like > complete overdesign. > > Let's not add system calls just because we can. > > Linus > The point of this is to give us the ability to monitor mounts from userspace. The original inspiration was rtnetlink, in that we need a "dump" operation to give us a snapshot of the current mount state, plus then a stream of events which allow us to keep that state updated. The tricky question is what happens in case of overflow of the events queue, and just like netlink, that needs a resync of the current state to fix that, since we can't block mounts, of course. The fsinfo syscall was designed to be the "dump" operation in this system. David's other patch set provides the stream of events. So the two are designed to work together. We had the discussion on using netlink, of whatever form a while back, and there are a number of reasons why that doesn't work (namespace being one). I think fstatfs might also suffer from the issue of not being easy to call on things for which you have no path (e.g. over-mounted mounts) Plus we need to know which paths to query, which is why we need to enumerate the mounts in the first place - how would we get the fds for each mount? It might give you some sb info, but it doesn't tell you the options that the sb is mounted with, and it doesn't tell you where it is mounted either. The overall aim is to solve some issues relating to scaling to large numbers of mount in systemd and autofs, and also to provide a generically useful interface that other tools may use to monitor mounts in due course too. Currently parsing /proc/mounts is the only option, and that tends to be slow and is certainly not atomic. Extension to other sb related messages is a future goal, quota being one possible application for the notifications. If there is a simpler way to get to that goal, then thats all to the good, and we should definitely consider it, Steve.