From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 30B0873441; Tue, 28 May 2024 08:20:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716884428; cv=none; b=MRq4bDo2Jv/XYbrXLXKTl27dG7OkFZh819CccitKel6yR4KPy5Tm74DmBQ8g4tPojGgZgp3nHNd58Eek6/y2tC5AbnQYutJu5jXSDHtde0Duvk6wTcTQ82eCAz5FDp8/lG/YdYOMkN9/jmrfws//Vpa3rzk9l5Poa1XLi6ZiNpU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716884428; c=relaxed/simple; bh=ef2GWcgmaUf0AdMfddAKzFxmIGHc4piX3DIDo9nhUc0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rZsgnG+Nr52vLQ8fTkrAYwzkieikBCg+Jy6YbXS9KdQDbemP939onNCNdY+tdzTzHb0igFddxm8WBN0my9FCuGAJPxbqU4uVPY5sCD1dAym6zcYco8rAso3QoKjwn08U1c9WgsH9C5eUUXT0yF5Dd1GXYU6tiMSeM4YAxdB3Wik= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mLomtxRc; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mLomtxRc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 94264C3277B; Tue, 28 May 2024 08:20:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1716884427; bh=ef2GWcgmaUf0AdMfddAKzFxmIGHc4piX3DIDo9nhUc0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mLomtxRcgnHVYUBmz5vFSVIxsxx1PZp4qr26Wmz7Liw21xHXDkjzoB1HlL7xhW+be EbcV452bPfpBt3tb1DNoLXvSaCS79QpKlD7mZAJ73dayzbUgFh0mhIdMP+HFocJTE8 J/1G+tULvUsHtvprZmNiuN9rvW4wShG+a34wfgp8YkXi0rpJ82OF+CHXMUbB6fzBgR aQk5nmm1cOXlcANGqqYN3JLLklGLKPYWt7dJhYHMviF5pEJBcTiDj/tp2IlXT1PMPA z2d6WpkNmVLMZVwm0AGxC3T5Z4QbpB/IQCmo0SkE2mWMEitf4PD/Ow8u5ZzGRFIa22 oULuaZSQjSCpQ== Date: Tue, 28 May 2024 10:20:21 +0200 From: Christian Brauner To: Christoph Hellwig Cc: Jan Kara , Aleksa Sarai , Alexander Viro , Chuck Lever , Jeff Layton , Amir Goldstein , Alexander Aring , linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org Subject: Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2) Message-ID: <20240528-wachdienst-weitreichend-42f8121bf764@brauner> References: <20240523-exportfs-u64-mount-id-v2-1-f9f959f17eb1@cyphar.com> <20240526.184753-detached.length.shallow.contents-jWkMukeD7VAC@cyphar.com> <20240527133430.ifjo2kksoehtuwrn@quack3> Precedence: bulk X-Mailing-List: linux-api@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: > Well, how about we fix the thing for real: > > - allow file systems to provide a uniqueu identifier of at least > uuid size (16 bytes) in the superblock or through an export operation > - for non-persistent file systems allow to generate one at boot time > using the normal uuid generation helpers > - add a new flag to name_to_handle_at/open_by_handle_at to include it > in the file handle, and thus make the file handle work more like > the normal file handle > - add code to nfsd to directly make use of this > > This would solve all the problems in this proposal as well as all the > obvious ones it doesn't solve. As I've said multiple times on the thread I agree that this is what we should do next and I would be happy to take patches for this. But exposing the 64bit mount id doesn't impede or complicate that work. It's a simple and useful addition that can be done now and doesn't prevent us from doing the proposed work. Hell, if you twist my arm I'll even write the patches for this.