Received: by 2002:a05:7412:798b:b0:fc:a2b0:25d7 with SMTP id fb11csp545757rdb; Thu, 22 Feb 2024 11:25:41 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXHU+U35/R6NkpaNvZLTeT0VG1O5Co/9vdPpFMNr40RFCQKl1pLAmyw+Q8BPW8T3d4jyQUxfYnjyOGQloSvHpnvMOuwyADCWm5CSCIzhA== X-Google-Smtp-Source: AGHT+IGVoqBOddpb08c0awtMGQwSNWukEerttBfnh2O+SPPGwldajT4VX43lYSKOoPlEwnVpQf5I X-Received: by 2002:a05:620a:4d04:b0:787:a7ef:7c1e with SMTP id wa4-20020a05620a4d0400b00787a7ef7c1emr1655797qkn.47.1708629941010; Thu, 22 Feb 2024 11:25:41 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708629940; cv=pass; d=google.com; s=arc-20160816; b=PXKUBEGTObJqaFaxIP7ONF9HaFgyZ7dJGgEb6TabKqY7evfQkVhRPfAPUfiyqZKY7l Z1W6lT8pV1lPIcQLSwJSe6jhdzGzyuvCL1EkjFIYpAAeuDu4UWxKS7uDQUGma9Daj6cR IUWfIG1+bpOlAGESrlxYjpCftfmsU2461RzcxXyvuIvirwKPsf7+/5/FWOU4+DiNr2Mw AHxLrgO/cSUeTvonBrYLW9thQSwuHgwxarHrHjF5hI55M7i0Q+QTdF5hO7iWXlN7CCM2 DdaJBCWuxbM79TVsVcIR14wm2oxjGgAtRCI8kXVRArT+a5rl2QzNqhSFe9uJGBLSH6ro O+1Q== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=QIa8oVIZuT7lP1k8X8l2WJQdq609coU/Nz2aGnBWwe4=; fh=UnRZ+CCHSfuLcUD0f03Mh7N9XA+0LxglOJVGhpu7/mM=; b=wJNXMYbc1gfyqOa4hi0sdXLXzTM2lWx1p/gRzxRlMQZBTBC092M/x6iNtz6SJLvJyv 9P/f03AhkBmL4QCwGHz4Ad+CY/UZK7ZFSaPBT3iWdqoJ1JgaYPJ46Wj4sB4ZEbwjf8Bo 65YGyF7GDq7HCp3cydysi2evjuBXF6xnLj87zFE5gyrOjFYo0Xb5KUX1tCPtdZFrlpDh bNeZ5zUp5VKTVjP5Soe1B2jvd5I0hGxhTybdFX+DPOce9DSz9Ze3F/9M2oQeS2JpKwTw B++GH7MfbM9TeRnWrzfKzm0CknQ8Vx1xpgLmu7+TDKdV1BoCRWdQvIuerDQjubqZ0Diq djFg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@toxicpanda-com.20230601.gappssmtp.com header.s=20230601 header.b=RIEywIvv; arc=pass (i=1 dkim=pass dkdomain=toxicpanda-com.20230601.gappssmtp.com); spf=pass (google.com: domain of linux-kernel+bounces-76813-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-76813-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id m18-20020a05620a24d200b0078722740a3esi14666864qkn.647.2024.02.22.11.25.40 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Feb 2024 11:25:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-76813-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@toxicpanda-com.20230601.gappssmtp.com header.s=20230601 header.b=RIEywIvv; arc=pass (i=1 dkim=pass dkdomain=toxicpanda-com.20230601.gappssmtp.com); spf=pass (google.com: domain of linux-kernel+bounces-76813-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-76813-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 7D5ED1C23304 for ; Thu, 22 Feb 2024 15:48:33 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B75E91509AF; Thu, 22 Feb 2024 15:48:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=toxicpanda-com.20230601.gappssmtp.com header.i=@toxicpanda-com.20230601.gappssmtp.com header.b="RIEywIvv" Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1B04B14D45C for ; Thu, 22 Feb 2024 15:48:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708616886; cv=none; b=PtRFZrtCv/cRVTq3trBL0CRAvUNiVKJkm2nHATXNUNZJZ7hTNB9wJ/y4z56rmRSMmxsYuaUcY61SEdcZKH60xXqtsruSk7aLBpb1t0pKFvyOtfrzyBEJOUFBCkCKCkaPX7Uph8ipqfF8Y8uHuW0PWMgG7WHfMz+VvoR8+nzkaHA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708616886; c=relaxed/simple; bh=/URg4PQnQQuQavo2tWzU6iVHhXxnRjfAkpj2MvvU244=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XIvISMy3yojNr8HlmF1rwCtVcNnwIkSTtf5m0/XLdiRsf44UoT2oPOf5FFekSqggvvJ+qycLhW/jLDbheT2ulk7fUvSJEaNXfVq61Gvp2X8bm6TS1A3aNfYEW/qYrWQ3mIHhnWa6YkKPG7EDqYLAhlb1rMEfMBthLJIOhj47khU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=toxicpanda.com; spf=none smtp.mailfrom=toxicpanda.com; dkim=pass (2048-bit key) header.d=toxicpanda-com.20230601.gappssmtp.com header.i=@toxicpanda-com.20230601.gappssmtp.com header.b=RIEywIvv; arc=none smtp.client-ip=209.85.219.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=toxicpanda.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=toxicpanda.com Received: by mail-yb1-f178.google.com with SMTP id 3f1490d57ef6-dcc86086c9fso2227172276.3 for ; Thu, 22 Feb 2024 07:48:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20230601.gappssmtp.com; s=20230601; t=1708616884; x=1709221684; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=QIa8oVIZuT7lP1k8X8l2WJQdq609coU/Nz2aGnBWwe4=; b=RIEywIvvscu1E8xViuV4ZuAJOikoT2p1+xmOQaCMPZpoQ5BUx/TnMjs2uOiFXVRR5t Phh57Z4wdTLREqHqs61NjoO3Iknt5R4e49VX887QUDXR/WQfNIjffCEOLEp+hzX2JfSQ 7mYiEamFKSWVW4qKy756x+ZdsL850EDSFBQ6aT2vDN0O6LWiu1D1IsEHpKgwq/EUuk+w fy1d5afa6gPYlpjt/rxtXtUmLRtfYb4zRb0KJR/wAf/ZwfTJ3VurlPCdyt1ySZZwf7Ey MW3R+XNomF88wZDCrC9WcSAzOoWZSHsPQfwAC2w8ZgWdrfCdK4VZeLpiBusKI1ZhDuIb BdSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708616884; x=1709221684; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=QIa8oVIZuT7lP1k8X8l2WJQdq609coU/Nz2aGnBWwe4=; b=gauiw+YZmn5lKgrSCHtQgk9IwYwT4H3JrYwzYY7hssoVOTxBLlZGj1R8BbCnfz6mRK tafG6p8Szk3xU8kss0GpfKgN5t5eYBReDvxFcG9yISlZPgAuyFjLBbex7bhkPPjnnByn oGZ5b0ucWqgkAD1Cr4te/EX+8kqEZLNY7CN09tQTWysGVPLw8itqTkK6E1Bh32cspOi4 rx4Q/5M8RWtzZxAcTJaO90knbIZYjctPdygAmcH6Tqpu/LJmpiE+almaoyAosQT1KbIC K1utFb3oAkmuur5OUh0jE4TfYLxpdhE+PlN2C/V6EO4mEvYneq6QZilr+wGZTllvBSfw c2WA== X-Forwarded-Encrypted: i=1; AJvYcCU6S89EclNcuMnYph0FyRaMYhxFLvNbU3SsHgHlKBRu8iNpYk+q5wHx8Y6I+zWBDf0lbcpb5bK1OkBYNW6ZiubQNaFE/Z2bCFYi8/9T X-Gm-Message-State: AOJu0YxQGSERh1uHYkmKE7VTTHtCAEzDleSSnqHldu0b7eG4UbHYE9y0 pGlgs4ypAcDkrRlt7dyYLJd6ty84d5SisTvOXcasFjlwFp9IqTkV/aVZqKE68XU= X-Received: by 2002:a25:8b85:0:b0:dcd:2f2d:7a05 with SMTP id j5-20020a258b85000000b00dcd2f2d7a05mr2616558ybl.35.1708616884094; Thu, 22 Feb 2024 07:48:04 -0800 (PST) Received: from localhost (076-182-020-124.res.spectrum.com. [76.182.20.124]) by smtp.gmail.com with ESMTPSA id w131-20020a253089000000b00dc25d5f4c75sm2942698ybw.10.2024.02.22.07.48.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Feb 2024 07:48:03 -0800 (PST) Date: Thu, 22 Feb 2024 10:48:02 -0500 From: Josef Bacik To: Miklos Szeredi Cc: Kent Overstreet , linux-bcachefs@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, lsf-pc@lists.linux-foundation.org Subject: Re: [LSF TOPIC] statx extensions for subvol/snapshot filesystems & more Message-ID: <20240222154802.GA1219527@perftesting> References: <2uvhm6gweyl7iyyp2xpfryvcu2g3padagaeqcbiavjyiis6prl@yjm725bizncq> <20240221210811.GA1161565@perftesting> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, Feb 22, 2024 at 10:14:20AM +0100, Miklos Szeredi wrote: > On Wed, 21 Feb 2024 at 22:08, Josef Bacik wrote: > > > > On Wed, Feb 21, 2024 at 04:06:34PM +0100, Miklos Szeredi wrote: > > > On Wed, 21 Feb 2024 at 01:51, Kent Overstreet wrote: > > > > > > > > Recently we had a pretty long discussion on statx extensions, which > > > > eventually got a bit offtopic but nevertheless hashed out all the major > > > > issues. > > > > > > > > To summarize: > > > > - guaranteeing inode number uniqueness is becoming increasingly > > > > infeasible, we need a bit to tell userspace "inode number is not > > > > unique, use filehandle instead" > > > > > > This is a tough one. POSIX says "The st_ino and st_dev fields taken > > > together uniquely identify the file within the system." > > > > > > > Which is what btrfs has done forever, and we've gotten yelled at forever for > > doing it. We have a compromise and a way forward, but it's not a widely held > > view that changing st_dev to give uniqueness is an acceptable solution. It may > > have been for overlayfs because you guys are already doing something special, > > but it's not an option that is afforded the rest of us. > > Overlayfs tries hard not to use st_dev to give uniqueness and instead > partitions the 64bit st_ino space within the same st_dev. There are > various fallback cases, some involve switching st_dev and some using > non-persistent st_ino. > > What overlayfs does may or may not be applicable to btrfs/bcachefs, > but that's not my point. My point is that adding a flag to statx does > not solve anything. You can't just say that from now on btrfs > doesn't have use unique st_ino/st_dev because we've just indicated > that in statx and everything is fine. That will trigger the > no-regressions rule and then it's game over. At least I would expect > that to happen. Right, nobody is arguing that. Our plan is to 1) Introduce some sort of statx mechanism to expose this information. 2) Introduce an incompat fs feature flag to give unique inode numbers for people that want them, and there stop doing the st_dev thing we currently do. 3) Continue doing the st_dev thing we currently do for the non-feature flag case. 4) Wait 50 years and then maybe stop doing the st_dev thing once people have adopted whatever statx flag has been introduced. God willing I will have been hit by a bus well before then. Nobody is arguing about reverting existing behavior, we're stuck with it. We're trying to define how we'd like it to look going forward, and start working towards that. Thanks, Josef