Received: by 2002:ab2:3319:0:b0:1ef:7a0f:c32d with SMTP id i25csp677069lqc; Fri, 8 Mar 2024 08:35:07 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCWjvmPldOcG+LIf34wHtLTy5PZ3PDDMeWt8MYdiaTrLbSP6XUJ7agFmvNY26iM9YAW+J4DeNv4jnGQz93reAyykwCp4sbfIt+Gw1sNZeQ== X-Google-Smtp-Source: AGHT+IGA97GWOzaL91vwOcmTAareqzXwOZoEZgNWwf14oFlIu55tH3xf9+QpgD5t9ci9rvqHXd1v X-Received: by 2002:a05:620a:88c:b0:787:ea8a:d048 with SMTP id b12-20020a05620a088c00b00787ea8ad048mr12473185qka.46.1709915707037; Fri, 08 Mar 2024 08:35:07 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1709915707; cv=pass; d=google.com; s=arc-20160816; b=CYD+B0XTB39yaEzg4+vHLi0eINXt2ITRbsbhsfZVUpAcm33kfFtTJhNpcQhfLgSY3T kmJp+z1J7mUB6xD3DY6PeSU4QrrNlXuFcdiaucjsUrDNDoI/gEM96wIY5tevVR5ddq00 kx4usurjKxyHSRgWvPS/pmYMSW7k6DA0olRFAuI6K+EeRleE0xahsEwmAAF7oPXFX8tn /bc+3ML9vUXbfD09dd1Arx70eUs1QwiI9eGnz1H0N3fEdpwTv0QfN4LkZ7bEtsWuhTbF 9jUiKEctmloqmeQgTTaG2id5ic8TgPM2ytsRSkmtipZPfFsv7PFpZjXrepSSbNeTmyhm nqZw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:message-id:subject:cc:to:from:dkim-signature:date; bh=ktBpMrN3UsrnXHVw4tN75j0kRv43XqLYLDOv9Qy1a30=; fh=0DzVikYI1m9Q6Uh1uNPiN7E9RKRN1dRDLVZnLsgBY/A=; b=qGRSCEyiHiJgGqojU1mu3mCl0kp+GSqeSNQMA9YX2t4eJTMTylPlNj4OwFacvFUflP uiiGycNzjnbnulaGYlPaW3f6g1svJeyA/S08eCnO5m4q4N/XV5hnx2YFVF9JDnGgoc6X ggEUKpyXFhT6DF1CwV5AiuaJywKb6v/jDacxe1QVMzn/vPjCQhiPMZZeC1HVRLKi6XxS x3q1cpFAQolXS3BFk5kupeIGPNWs2FwqRvs/Rh3Bm9jEqetd+C67viKLHEqyTqg4mF/s r5PUswJEz4KnKx4tpepUoUoKbePIh+whmnW7QO/PcNrh4IStaeOkEVUZS3ktwBtXGGYi +ogQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=jGZ9Enx7; arc=pass (i=1 spf=pass spfdomain=linux.dev dkim=pass dkdomain=linux.dev dmarc=pass fromdomain=linux.dev); spf=pass (google.com: domain of linux-kernel+bounces-97311-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-97311-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id yf7-20020a05620a3bc700b007884164b882si5337065qkn.561.2024.03.08.08.35.06 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Mar 2024 08:35:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-97311-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=@linux.dev header.s=key1 header.b=jGZ9Enx7; arc=pass (i=1 spf=pass spfdomain=linux.dev dkim=pass dkdomain=linux.dev dmarc=pass fromdomain=linux.dev); spf=pass (google.com: domain of linux-kernel+bounces-97311-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-97311-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev 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 B40271C21268 for ; Fri, 8 Mar 2024 16:35:06 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A52FDDDD7; Fri, 8 Mar 2024 16:34:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="jGZ9Enx7" Received: from out-178.mta1.migadu.com (out-178.mta1.migadu.com [95.215.58.178]) (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 91ADA33CC for ; Fri, 8 Mar 2024 16:34:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709915689; cv=none; b=kclFwv8LMqz7m6uEn8AF8bFYP5DYde1s58QbZ5RU6am0mWgFqocI3cYaNg2WohIkAH+OZqfLJhGL3pZpzFUWG7ib041oW/hi3yEs4DSHM7mAasb7xC/WnLuIr+FoC8WjTMptSH9/m/l9Fs2BgY8DA/ue8GPUGKwCObK+O9omlvU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709915689; c=relaxed/simple; bh=4ZhLwiZ0RDhrZTBGJXvOEEK8z8sfiISfXZm+4nEozaY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Iihm4Upoar2hYSzwWKKHzbVLDa4sweTSSkOVjVd6m4+F1zaHDeYlpOgWUaN7MZ9dLPrV3GjQX1+yvxok35LGCD3+gRMWHJwpch15er8DemyJMu32VfMxyzqPsuL4CkP66rHFLCrn+bcyCKce8fozd+usbes5SElgR0Xqg4EMPmg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=jGZ9Enx7; arc=none smtp.client-ip=95.215.58.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Date: Fri, 8 Mar 2024 11:34:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1709915685; h=from:from:reply-to:subject:subject: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=ktBpMrN3UsrnXHVw4tN75j0kRv43XqLYLDOv9Qy1a30=; b=jGZ9Enx7ssxLGkvSXWH7xl+QFlnSXT7I0ydFpvFfbhXUdxui+zVeJ0kvwMw0O7YpBUcsOp Y3jE7Nw0RdAd6Vugm1brtUt8De96L6ASeiGXMKa10wIAXOLcR+aguj/IIJkF5xF5gLfiIp jM7RuTVe17883wuzKU9zSOQRbSOVUdA= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Neal Gompa Cc: linux-fsdevel@vger.kernel.org, linux-bcachefs@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, Josef Bacik , Miklos Szeredi , Christian Brauner , David Howells Subject: Re: [PATCH v2] statx: stx_subvol Message-ID: References: <20240308022914.196982-1-kent.overstreet@linux.dev> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Migadu-Flow: FLOW_OUT On Fri, Mar 08, 2024 at 06:42:27AM -0500, Neal Gompa wrote: > On Thu, Mar 7, 2024 at 9:29 PM Kent Overstreet > wrote: > > > > Add a new statx field for (sub)volume identifiers, as implemented by > > btrfs and bcachefs. > > > > This includes bcachefs support; we'll definitely want btrfs support as > > well. > > > > Link: https://lore.kernel.org/linux-fsdevel/2uvhm6gweyl7iyyp2xpfryvcu2g3padagaeqcbiavjyiis6prl@yjm725bizncq/ > > Signed-off-by: Kent Overstreet > > Cc: Josef Bacik > > Cc: Miklos Szeredi > > Cc: Christian Brauner > > Cc: David Howells > > Signed-off-by: Kent Overstreet > > --- > > fs/bcachefs/fs.c | 3 +++ > > fs/stat.c | 1 + > > include/linux/stat.h | 1 + > > include/uapi/linux/stat.h | 4 +++- > > 4 files changed, 8 insertions(+), 1 deletion(-) > > > > diff --git a/fs/bcachefs/fs.c b/fs/bcachefs/fs.c > > index 3f073845bbd7..6a542ed43e2c 100644 > > --- a/fs/bcachefs/fs.c > > +++ b/fs/bcachefs/fs.c > > @@ -840,6 +840,9 @@ static int bch2_getattr(struct mnt_idmap *idmap, > > stat->blksize = block_bytes(c); > > stat->blocks = inode->v.i_blocks; > > > > + stat->subvol = inode->ei_subvol; > > + stat->result_mask |= STATX_SUBVOL; > > + > > if (request_mask & STATX_BTIME) { > > stat->result_mask |= STATX_BTIME; > > stat->btime = bch2_time_to_timespec(c, inode->ei_inode.bi_otime); > > diff --git a/fs/stat.c b/fs/stat.c > > index 77cdc69eb422..70bd3e888cfa 100644 > > --- a/fs/stat.c > > +++ b/fs/stat.c > > @@ -658,6 +658,7 @@ cp_statx(const struct kstat *stat, struct statx __user *buffer) > > tmp.stx_mnt_id = stat->mnt_id; > > tmp.stx_dio_mem_align = stat->dio_mem_align; > > tmp.stx_dio_offset_align = stat->dio_offset_align; > > + tmp.stx_subvol = stat->subvol; > > > > return copy_to_user(buffer, &tmp, sizeof(tmp)) ? -EFAULT : 0; > > } > > diff --git a/include/linux/stat.h b/include/linux/stat.h > > index 52150570d37a..bf92441dbad2 100644 > > --- a/include/linux/stat.h > > +++ b/include/linux/stat.h > > @@ -53,6 +53,7 @@ struct kstat { > > u32 dio_mem_align; > > u32 dio_offset_align; > > u64 change_cookie; > > + u64 subvol; > > }; > > > > /* These definitions are internal to the kernel for now. Mainly used by nfsd. */ > > diff --git a/include/uapi/linux/stat.h b/include/uapi/linux/stat.h > > index 2f2ee82d5517..67626d535316 100644 > > --- a/include/uapi/linux/stat.h > > +++ b/include/uapi/linux/stat.h > > @@ -126,8 +126,9 @@ struct statx { > > __u64 stx_mnt_id; > > __u32 stx_dio_mem_align; /* Memory buffer alignment for direct I/O */ > > __u32 stx_dio_offset_align; /* File offset alignment for direct I/O */ > > + __u64 stx_subvol; /* Subvolume identifier */ > > /* 0xa0 */ > > - __u64 __spare3[12]; /* Spare space for future expansion */ > > + __u64 __spare3[11]; /* Spare space for future expansion */ > > /* 0x100 */ > > }; > > > > @@ -155,6 +156,7 @@ struct statx { > > #define STATX_MNT_ID 0x00001000U /* Got stx_mnt_id */ > > #define STATX_DIOALIGN 0x00002000U /* Want/got direct I/O alignment info */ > > #define STATX_MNT_ID_UNIQUE 0x00004000U /* Want/got extended stx_mount_id */ > > +#define STATX_SUBVOL 0x00008000U /* Want/got stx_subvol */ > > > > #define STATX__RESERVED 0x80000000U /* Reserved for future struct statx expansion */ > > > > -- > > 2.43.0 > > > > > > I think it's generally expected that patches that touch different > layers are split up. That is, we should have a patch that adds the > capability and a separate patch that enables it in bcachefs. This also > helps make it clearer to others how a new feature should be plumbed > into a filesystem. > > I would prefer it to be split up in this manner for this reason. I'll do it that way if the patch is big enough that it ought to be split up. For something this small, seeing how it's used is relevant context for both reviewers and people looking at it afterwards.