Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp611310pxv; Thu, 15 Jul 2021 11:28:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwq0qSTNbOSwBmYplaWMsNLKUktC0x/7XvbM6DswoAuSgEBnuas/mgq2XkqAnQn33M9RJzd X-Received: by 2002:a02:cd0a:: with SMTP id g10mr5173628jaq.18.1626373733978; Thu, 15 Jul 2021 11:28:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626373733; cv=none; d=google.com; s=arc-20160816; b=vWxY5xN3qiTuBPZ1krES8P8VRfsFuk3pyabB+qVYUnBG+r8XvdyoFgDGJEZ+pUrUYo WclUxgmg6s4zrW7VgSEGJuyR0OJFsMDhNUdUubVZJ3H/b2b9w7i4jMIz43y4sUSIApbW LpgEXygSqk+FdtQkgRhFkKDfXfcmMs/5MciPQ00A+unJwpAHPieXTilJg3QTHXJNNzpy 845p9l4WqvZKbTiBAyVOlUMlWUX+++l9EhHhLxCZ+59ci9bU1upecp7rfo8mIo8TFbtU Jo4iG/cA3id0yn783z/xcbXGG7tEP1W0ElKKeHLADswdCkX7dXySUXlNvuxxubc1dG6M dCGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=Z0Gk2SeFQAuabVMnx7xvlDltWtB4GVuvBbjKfVTW53E=; b=HxAZeVJpMRydHVmezinfvx7xL9jhn06yl0hiBj0+VbeOOfb0tG6p0piiw55MI0HSdq Dg06RE5CTAswjF2WKWQGVCpqJMUwe/VTuvWef9+Eu/LI9yr8wMgAymlsD6wobG0f2Ylv kcInZ4Xf1EAIvWfZKX9cLg8CFFqjfwINKUo975FZCcUdV50zZun2ggfUABYy0JP92CfS SfjxoWiAZCtLBxk1UYtTF8mzo+jbrtv7kone0oVpQcCb8nYgSi5SThlazOKd1xThvbL3 mhurnJs+mwhufePSND5IiFpcsGkZhMNwyrQWWaULCnk2G6jTUYLahierhgw4bzQH9wZC zv4A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@toxicpanda-com.20150623.gappssmtp.com header.s=20150623 header.b=U1UMjmFd; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v17si7667849ilo.17.2021.07.15.11.28.34; Thu, 15 Jul 2021 11:28:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-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=@toxicpanda-com.20150623.gappssmtp.com header.s=20150623 header.b=U1UMjmFd; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237114AbhGOSEJ (ORCPT + 99 others); Thu, 15 Jul 2021 14:04:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45960 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237099AbhGOSEJ (ORCPT ); Thu, 15 Jul 2021 14:04:09 -0400 Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7CD5AC06175F for ; Thu, 15 Jul 2021 11:01:15 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id c9so5145129qte.6 for ; Thu, 15 Jul 2021 11:01:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Z0Gk2SeFQAuabVMnx7xvlDltWtB4GVuvBbjKfVTW53E=; b=U1UMjmFdrYSaRSKHzjI4EvNxYqUYc/WS/hsktV+dGKYUxN0o0GpfjmXEx67j00m0WK mETCsF7HPd7zgNxtdZkjT8fhSciLvURI+iUSFscc8AFjgIqGs1cmf7Crn8OBoAb+rm5i x8Q+ohSDtuhn7Y6xO/tLnYEpIDZJU/jdoasA6hjC/JOGbULn7HToTOX85abOXYY2zUdQ rAXXjAd0MovAyYFScIMAihuzkR/6JG+HsBMzGxrwvghs7jLI+JHE2dvGklFLNNt3oFDT J094+yVpMicxb7G6D8JMS9nVfWFn97H2Xk3Htesy7LLRwvRkGuv2IV48LxaEyzWmGKOa oq1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Z0Gk2SeFQAuabVMnx7xvlDltWtB4GVuvBbjKfVTW53E=; b=WOHBhahONLt+VSxmwmRXYUb0UKmRmWWAFxuYe/0mLFFTa83yr4xPa7zKtXkqNTavB7 WQyYJrd9EPWugP6ARGsS8IFGsECl9y1lwuKNEg73Q/XVcZeK3ltxhK+L7HvWbgQfrrEY u0r0s/XzWYpyypq2g1vu+4CYkSGzOtiq2SX1m48KXWuM6cMYVQ8S5u0mh3CI97+FtstF T3UAcRMmFO+rBcAzOv1qK8KS3krifR6zHui74e3aGB2KZ2NTtxzDtZKIhZqYuRObc5ZY cZZc3Ikl5VaxVt3FJE8+9pao6RY+CSRqAjCcinCmSse60ePHTEyeTrYG6jlri1PpBsrQ zZ4Q== X-Gm-Message-State: AOAM533q8BpTsS2vXAiQB0lM+1GARjHLzsne1LH1TIpoBG+pdYgqavwY xc+DQHRK11U22dqDMMKsmXoi1Q== X-Received: by 2002:ac8:5f4b:: with SMTP id y11mr5009123qta.288.1626372074496; Thu, 15 Jul 2021 11:01:14 -0700 (PDT) Received: from ?IPv6:2620:10d:c0a8:11e8::11fa? ([2620:10d:c091:480::1:7357]) by smtp.gmail.com with ESMTPSA id e12sm2364268qtj.3.2021.07.15.11.01.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jul 2021 11:01:13 -0700 (PDT) Subject: Re: [PATCH/RFC] NFSD: handle BTRFS subvolumes better. To: Christoph Hellwig Cc: NeilBrown , "J. Bruce Fields" , Chuck Lever , Chris Mason , David Sterba , linux-nfs@vger.kernel.org, Wang Yugui , Ulli Horlacher , linux-btrfs@vger.kernel.org References: <20210613115313.BC59.409509F4@e16-tech.com> <20210310074620.GA2158@tik.uni-stuttgart.de> <162632387205.13764.6196748476850020429@noble.neil.brown.name> <28bb883d-8d14-f11a-b37f-d8e71118f87f@toxicpanda.com> From: Josef Bacik Message-ID: Date: Thu, 15 Jul 2021 14:01:11 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On 7/15/21 1:24 PM, Christoph Hellwig wrote: > On Thu, Jul 15, 2021 at 01:11:29PM -0400, Josef Bacik wrote: >> Because there's no alternative. We need a way to tell userspace they've >> wandered into a different inode namespace. There's no argument that what >> we're doing is ugly, but there's never been a clear "do X instead". Just a >> lot of whinging that btrfs is broken. This makes userspace happy and is >> simple and straightforward. I'm open to alternatives, but there have been 0 >> workable alternatives proposed in the last decade of complaining about it. > > Make sure we cross a vfsmount when crossing the "st_dev" domain so > that it is properly reported. Suggested many times and ignored all > the time beause it requires a bit of work. > You keep telling me this but forgetting that I did all this work when you originally suggested it. The problem I ran into was the automount stuff requires that we have a completely different superblock for every vfsmount. This is fine for things like nfs or samba where the automount literally points to a completely different mount, but doesn't work for btrfs where it's on the same file system. If you have 1000 subvolumes and run sync() you're going to write the superblock 1000 times for the same file system. You are going to reclaim inodes on the same file system 1000 times. You are going to reclaim dcache on the same filesytem 1000 times. You are also going to pin 1000 dentries/inodes into memory whenever you wander into these things because the super is going to hold them open. This is not a workable solution. It's not a matter of simply tying into existing infrastructure, we'd have to completely rework how the VFS deals with this stuff in order to be reasonable. And when I brought this up to Al he told me I was insane and we absolutely had to have a different SB for every vfsmount, which means we can't use vfsmount for this, which means we don't have any other options. Thanks, Josef