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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 898E9C433EF for ; Thu, 2 Sep 2021 23:02:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7082660F42 for ; Thu, 2 Sep 2021 23:02:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348021AbhIBXDb (ORCPT ); Thu, 2 Sep 2021 19:03:31 -0400 Received: from smtp-out2.suse.de ([195.135.220.29]:48734 "EHLO smtp-out2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348000AbhIBXDa (ORCPT ); Thu, 2 Sep 2021 19:03:30 -0400 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id F3C171FFE4; Thu, 2 Sep 2021 23:02:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1630623751; h=from:from:reply-to: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=sU28DzaSgjn8Ql/BUOqdBFP2o4qesH20RR4IjIyMuF4=; b=BV/Y1O2QOlMnvcDCFHBW5u4CZzwb5UwK+14iVsUp8deI6QkiBxqDD6rTgDljwOJCATC64V BIG6Tl0KEevu9CuYZYLZReHxXiLeh4tKIDcJhX8VD3XaSe3OFwHv/qBvZRdaqRu+LOrSaZ cfVQ8ETVtOe6uU0VXy/vlsnrsLyubyc= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1630623751; h=from:from:reply-to: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=sU28DzaSgjn8Ql/BUOqdBFP2o4qesH20RR4IjIyMuF4=; b=5x4AdmosLbJvXRAfIJVIUF+zN5yMnEllEraQRyxt2IgxIrkG1mgfEkLVNEe3ZEHfZDYbKi bhnkEEby14DNpsAQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 99D4C13AAB; Thu, 2 Sep 2021 23:02:28 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id iiklFgRYMWH9RwAAMHmgww (envelope-from ); Thu, 02 Sep 2021 23:02:28 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 From: "NeilBrown" To: "Frank Filz" Cc: "'Miklos Szeredi'" , "'Christoph Hellwig'" , "'J. Bruce Fields'" , "'Chuck Lever'" , "'Linux NFS list'" , "'Josef Bacik'" , linux-fsdevel@vger.kernel.org Subject: RE: [PATCH v2] BTRFS/NFSD: provide more unique inode number for btrfs export In-reply-to: <024601d7a005$1b3863c0$51a92b40$@mindspring.com> References: <162995209561.7591.4202079352301963089@noble.neil.brown.name>, <162995778427.7591.11743795294299207756@noble.neil.brown.name>, , <163010550851.7591.9342822614202739406@noble.neil.brown.name>, , <163038594541.7591.11109978693705593957@noble.neil.brown.name>, , <163055561473.24419.12486186372497472066@noble.neil.brown.name>, , , <024601d7a005$1b3863c0$51a92b40$@mindspring.com> Date: Fri, 03 Sep 2021 09:02:25 +1000 Message-id: <163062374563.24419.8930722817731828791@noble.neil.brown.name> Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Fri, 03 Sep 2021, Frank Filz wrote: > > On Thu, 2 Sept 2021 at 09:18, Christoph Hellwig wrote: > >=20 > > > > Your attitude seems to be that this is a btrfs problem and must be > > > > fixed in btrfs. > > > > > > Yes. > >=20 > > st_ino space issues affect overlayfs as well. The two problems are > > not the same, but do share some characteristics. And this limitation wil= l likely > > come up again in the future. > >=20 > > I suspect the long term solution would involve introducing new userspace = API > > (variable length inode numbers) and deprecating st_ino. > > E.g. make stat return an error if the inode number doesn't fit into st_in= o and add > > a statx extension to return the full number. But this would be a long pr= ocess... >=20 > But then what do we do where fileid in NFS is only 64 bits? Hence my suggestion that user-space should move to using the filehandle. Two file handles being different doesn't guarantee that the two objects are different, but the problems caused by incorrectly assuming two things are different are much less than the problems caused by incorrectly assuming two things are the same. >=20 > The solution of giving each subvol a separate fsid is the only real > solution to enlarging the NFS fileid space, however that has downsides > on the client side. And this doesn't help overlayfs... =20 NeilBrown