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 1D5D2C432BE for ; Mon, 2 Aug 2021 05:33:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E5BCF60F70 for ; Mon, 2 Aug 2021 05:33:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229888AbhHBFdN (ORCPT ); Mon, 2 Aug 2021 01:33:13 -0400 Received: from zeniv-ca.linux.org.uk ([142.44.231.140]:60134 "EHLO zeniv-ca.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229792AbhHBFdM (ORCPT ); Mon, 2 Aug 2021 01:33:12 -0400 Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mAQSS-005v4j-Vb; Mon, 02 Aug 2021 05:25:49 +0000 Date: Mon, 2 Aug 2021 05:25:48 +0000 From: Al Viro To: NeilBrown Cc: Miklos Szeredi , Christoph Hellwig , Josef Bacik , "J. Bruce Fields" , Chuck Lever , Chris Mason , David Sterba , linux-fsdevel@vger.kernel.org, Linux NFS list , Btrfs BTRFS Subject: Re: A Third perspective on BTRFS nfsd subvol dev/inode number issues. Message-ID: References: <162742539595.32498.13687924366155737575.stgit@noble.brown> <162742546548.32498.10889023150565429936.stgit@noble.brown> <162762290067.21659.4783063641244045179@noble.neil.brown.name> <162762562934.21659.18227858730706293633@noble.neil.brown.name> <162763043341.21659.15645923585962859662@noble.neil.brown.name> <162787790940.32159.14588617595952736785@noble.neil.brown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <162787790940.32159.14588617595952736785@noble.neil.brown.name> Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Mon, Aug 02, 2021 at 02:18:29PM +1000, NeilBrown wrote: > It think we need to bite-the-bullet and decide that 64bits is not > enough, and in fact no number of bits will ever be enough. overlayfs > makes this clear. Sure - let's go for broke and use XML. Oh, wait - it's 8 months too early... > So I think we need to strongly encourage user-space to start using > name_to_handle_at() whenever there is a need to test if two things are > the same. ... and forgetting the inconvenient facts, such as that two different fhandles may correspond to the same object. > I accept that I'm proposing some BIG changes here, and they might break > things. But btrfs is already broken in various ways. I think we need a > goal to work towards which will eventually remove all breakage and still > have room for expansion. I think that must include: > > - providing as-unique-as-practical inode numbers across the whole > filesystem, and deprecating the internal use of different device > numbers. Make it possible to mount without them ASAP, and aim to > make that the default eventually. > - working with user-space tool/library developers to use > name_to_handle_at() to identify inodes, only using st_ino > as a fall-back > - adding filehandles to various /proc etc files as needed, either > duplicating lines or duplicating files. And helping application which > use these files to migrate (I would *NOT* change the dev numbers in > the current file to report the internal btrfs dev numbers the way that > SUSE does. I would prefer that current breakage could be used to > motivate developers towards depending instead on fhandles). > - exporting subtree (aka subvol) id to user-space, possibly paralleling > proj_id in some way, and extending various tools to understand > subtrees > > Who's with me?? Cf. "Poe Law"...