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=-3.8 required=3.0 tests=BAYES_00, 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 559C5C4338F for ; Sun, 15 Aug 2021 19:35:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2054E6128E for ; Sun, 15 Aug 2021 19:35:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229743AbhHOTfj convert rfc822-to-8bit (ORCPT ); Sun, 15 Aug 2021 15:35:39 -0400 Received: from rin.romanrm.net ([51.158.148.128]:41256 "EHLO rin.romanrm.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229502AbhHOTfj (ORCPT ); Sun, 15 Aug 2021 15:35:39 -0400 Received: from natsu (natsu2.home.romanrm.net [IPv6:fd39::e99e:8f1b:cfc9:ccb8]) by rin.romanrm.net (Postfix) with SMTP id 105091A0; Sun, 15 Aug 2021 19:35:05 +0000 (UTC) Date: Mon, 16 Aug 2021 00:35:05 +0500 From: Roman Mamedov To: Goffredo Baroncelli Cc: NeilBrown , 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 Subject: Re: [PATCH] VFS/BTRFS/NFSD: provide more unique inode number for btrfs export Message-ID: <20210816003505.7b3e9861@natsu> In-Reply-To: References: <162742539595.32498.13687924366155737575.stgit@noble.brown> <162881913686.1695.12479588032010502384@noble.neil.brown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Sun, 15 Aug 2021 09:39:08 +0200 Goffredo Baroncelli wrote: > I am sure that it was discussed already but I was unable to find any track > of this discussion. But if the problem is the collision between the inode > number of different subvolume in the nfd export, is it simpler if the export > is truncated to the subvolume boundary ? It would be more coherent with the > current behavior of vfs+nfsd. See this bugreport thread which started it all: https://www.spinics.net/lists/linux-btrfs/msg111172.html In there the reporting user replied that it is strongly not feasible for them to export each individual snapshot. > In fact in btrfs a subvolume is a complete filesystem, with an "own > synthetic" device. We could like or not this solution, but this solution is > the more aligned to the unix standard, where for each filesystem there is a > pair (device, inode-set). NFS (by default) avoids to cross the boundary > between the filesystems. So why in BTRFS this should be different ? >From the user point of view subvolumes are basically directories; that they are "complete filesystems"* is merely a low-level implementation detail. * well except they are not, as you cannot 'dd' a subvolume to another blockdevice. > Why don't rename "ino_uniquifier" as "ino_and_subvolume" and leave to the > filesystem the work to combine the inode and the subvolume-id ? > > I am worried that the logic is split between the filesystem, which > synthesizes the ino_uniquifier, and to NFS which combine to the inode. I am > thinking that this combination is filesystem specific; for BTRFS is a simple > xor but for other filesystem may be a more complex operation, so leaving an > half in the filesystem and another half to the NFS seems to not optimal if > other filesystem needs to use ino_uniquifier. I wondered a bit myself, what are the downsides of just doing the uniquefication inside Btrfs, not leaving that to NFSD? I mean not even adding the extra stat field, just return the inode itself with that already applied. Surely cannot be any worse collision-wise, than different subvolumes straight up having the same inode numbers as right now? Or is it a performance concern, always doing more work, for something which only NFSD has needed so far. -- With respect, Roman