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=-5.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 B48DEC433DF for ; Wed, 12 Aug 2020 09:43:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 940B520838 for ; Wed, 12 Aug 2020 09:43:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="MvAgy4OJ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727048AbgHLJnx (ORCPT ); Wed, 12 Aug 2020 05:43:53 -0400 Received: from us-smtp-1.mimecast.com ([207.211.31.81]:51459 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727017AbgHLJnx (ORCPT ); Wed, 12 Aug 2020 05:43:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1597225431; 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=OdzUOSJMEbqrLIXBeiGU3Aa/BNw7IZScNhKdcrSD0Jw=; b=MvAgy4OJZt4+1W3P50zRujnQtyNLV7VOKeMN8fgc5qVJFw2q2+znW9Odxt2CGuJGBQKE7B QPkVU7ovwZX8qdZ3CZeluTgSeTKVmlQKNvt7Wgk4/0uhwNKerWu3AGi/pNWgAZmiKkVsOt ROOzX2i1p+HG6HhuuhtQ85jXcwawgdw= 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-139-ws1TaZzyOwGDwINq-6ki_Q-1; Wed, 12 Aug 2020 05:43:50 -0400 X-MC-Unique: ws1TaZzyOwGDwINq-6ki_Q-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4387279ED6; Wed, 12 Aug 2020 09:43:48 +0000 (UTC) Received: from fogou.chygwyn.com (unknown [10.33.36.12]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7BCF019D7B; Wed, 12 Aug 2020 09:43:33 +0000 (UTC) Subject: Re: file metadata via fs API To: Miklos Szeredi Cc: David Howells , Linus Torvalds , 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> <98802.1597220949@warthog.procyon.org.uk> From: Steven Whitehouse Message-ID: Date: Wed, 12 Aug 2020 10:43:24 +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.23 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org Hi, On 12/08/2020 09:37, Miklos Szeredi wrote: [snip] > > b) The awarded performance boost is not warranted for the use cases it > is designed for. > > Thanks, > Miklos > This is a key point. One of the main drivers for this work is the efficiency improvement for large numbers of mounts. Ian and Karel have already provided performance measurements showing a significant benefit compared with what we have today. If you want to propose this alternative interface then you need to show that it can sustain similar levels of performance, otherwise it doesn't solve the problem. So performance numbers here would be helpful. Also - I may have missed this earlier in the discussion, what are the atomicity guarantees with this proposal? This is the other key point for the API, so it would be good to see that clearly stated (i.e. how does one use it in combination with the notifications to provide an up to date, consistent view of the kernel's mounts) Steve.