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=-7.5 required=3.0 tests=BAYES_00,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 53233C432BE for ; Wed, 28 Jul 2021 13:53:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3CD496023E for ; Wed, 28 Jul 2021 13:53:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237193AbhG1Nwx (ORCPT ); Wed, 28 Jul 2021 09:52:53 -0400 Received: from zaphod.cobb.me.uk ([213.138.97.131]:43140 "EHLO zaphod.cobb.me.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236383AbhG1NtS (ORCPT ); Wed, 28 Jul 2021 09:49:18 -0400 X-Greylist: delayed 311 seconds by postgrey-1.27 at vger.kernel.org; Wed, 28 Jul 2021 09:49:18 EDT Received: by zaphod.cobb.me.uk (Postfix, from userid 107) id 353AF9BEE9; Wed, 28 Jul 2021 14:43:56 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cobb.uk.net; s=201703; t=1627479836; bh=AVprTXs7DyGHj0L7AmX18qLo2Z3rK1/x2Gl7dXunk0c=; h=From:To:Cc:References:Subject:Date:In-Reply-To:From; b=j/AOuRhcsm9Fh3e9IjFUxnYE+MZlKk3RcBRBNJJ3pNrlYgrR8DN4MFN2aLPxp8aSe OA6An2ZqEuoP0Ck+aq9L7PNTeB57wCAE71hI3LNtMFKpuEfnmiHjM+lyELtvCi4Qzp ZI1En+NZJ6umUjrlKrv0pNk8vFiYlQiPhhKUqryZeWCCKRWL1LMTMAR7Lh0Yk9ca4H 3NRaVL/+5O41psOKyHCvZbNpstxMt7f2bxr4nbhsLtZyCHASwjmSOGBTxFhvY9O12I 9OilWmVguUJkHI9RUBriJvjW8KWZPhgf5YalC1KGMHIikghy3sNeIXMTBvdHF+msaH KNOVOYCQweWDA== Received: from black.home.cobb.me.uk (unknown [192.168.0.205]) by zaphod.cobb.me.uk (Postfix) with ESMTP id F3F339B846; Wed, 28 Jul 2021 14:43:52 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cobb.uk.net; s=201703; t=1627479833; bh=AVprTXs7DyGHj0L7AmX18qLo2Z3rK1/x2Gl7dXunk0c=; h=From:To:Cc:References:Subject:Date:In-Reply-To:From; b=Z6Jkm+JubTCKlQzFQC7kdv34buXMMFdGTRl0xbnIQMBu2D9WNo/T0dKFwZBvSpVzb CsXLqPq+mjMzbHKiqUUUasWfG5vRSLoEUQTZ2g5VYI8AH/CQAV4spRcLI+CmussRPT Wy0S7XH2GWbrFldyF9CvDJRZ5BAyxN8rUmSogjUu4ZXu5zgr5U9GuPhsu8yE+GMgsa c6INNSNPs7vrmGj7TyKDdD23JAr75chB8Xq/3wkaLa2OOAm6H78bETe/IJEbIikb3y Vu0QtVHihqTk8gdAjHsyMJzV4SRkQuSaJh4M4uM+URDtzrsDWVKl2d2T6EHUjqwZK2 GefGpOz9uCYjA== Received: from [192.168.0.202] (ryzen.home.cobb.me.uk [192.168.0.202]) by black.home.cobb.me.uk (Postfix) with ESMTP id A5D6027556C; Wed, 28 Jul 2021 14:43:52 +0100 (BST) From: g.btrfs@cobb.uk.net To: NeilBrown , Wang Yugui Cc: Christoph Hellwig , Josef Bacik , "J. Bruce Fields" , Chuck Lever , Chris Mason , David Sterba , Alexander Viro , linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-btrfs@vger.kernel.org References: <162742539595.32498.13687924366155737575.stgit@noble.brown> <20210728125819.6E52.409509F4@e16-tech.com> <20210728140431.D704.409509F4@e16-tech.com> <162745567084.21659.16797059962461187633@noble.neil.brown.name> Subject: Re: [PATCH/RFC 00/11] expose btrfs subvols in mount table correctly Message-ID: <2cb6455c-7b9f-9ac3-fd9d-9121eb1aa109@cobb.uk.net> Date: Wed, 28 Jul 2021 14:43:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <162745567084.21659.16797059962461187633@noble.neil.brown.name> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On 28/07/2021 08:01, NeilBrown wrote: > On Wed, 28 Jul 2021, Wang Yugui wrote: >> Hi, >> >> This patchset works well in 5.14-rc3. > > Thanks for testing. > >> >> 1, fixed dummy inode(255, BTRFS_FIRST_FREE_OBJECTID - 1 ) is changed to >> dynamic dummy inode(18446744073709551358, or 18446744073709551359, ...) > > The BTRFS_FIRST_FREE_OBJECTID-1 was a just a hack, I never wanted it to > be permanent. > The new number is ULONG_MAX - subvol_id (where subvol_id starts at 257 I > think). > This is a bit less of a hack. It is an easily available number that is > fairly unique. > >> >> 2, btrfs subvol mount info is shown in /proc/mounts, even if nfsd/nfs is >> not used. >> /dev/sdc btrfs 94G 3.5M 93G 1% /mnt/test >> /dev/sdc btrfs 94G 3.5M 93G 1% /mnt/test/sub1 >> /dev/sdc btrfs 94G 3.5M 93G 1% /mnt/test/sub2 >> >> This is a visiual feature change for btrfs user. > > Hopefully it is an improvement. But it is certainly a change that needs > to be carefully considered. Would this change the behaviour of findmnt? I have several scripts that depend on findmnt to select btrfs filesystems. Just to take a couple of examples (using the example shown above): my scripts would depend on 'findmnt --target /mnt/test/sub1 -o target' providing /mnt/test, not the subvolume; and another script would depend on 'findmnt -t btrfs --mountpoint /mnt/test/sub1' providing no output as the directory is not an /etc/fstab mount point for a btrfs filesystem. Maybe findmnt isn't affected? Or maybe the change is worth making anyway? But it needs to be carefully considered if it breaks existing user interfaces.