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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2D8C5EB64D9 for ; Tue, 27 Jun 2023 14:19:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BD3918D0002; Tue, 27 Jun 2023 10:19:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B834E8D0001; Tue, 27 Jun 2023 10:19:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A4AF58D0002; Tue, 27 Jun 2023 10:19:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 966048D0001 for ; Tue, 27 Jun 2023 10:19:44 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 5F6C9C09FD for ; Tue, 27 Jun 2023 14:19:44 +0000 (UTC) X-FDA: 80948736288.06.5AEFB17 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf16.hostedemail.com (Postfix) with ESMTP id 0E4EF180022 for ; Tue, 27 Jun 2023 14:19:41 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=e2yOo3hq; spf=pass (imf16.hostedemail.com: domain of jlayton@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=jlayton@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687875582; h=from:from:sender: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:dkim-signature; bh=Kg0oEjdzgulDO0g4qNXV/6g4eD+pg1i9NjIeehDQq64=; b=hiXVy8pBuTVop28HebicOBvmaynXYX7NxMdsYjrFl+UFaZftqtxxk2pNbQhAUPKFZvF2hv /liHXcMTO7M5EVVBUYFvHvYNmOouTrqhGfy92L+si3cW1cjTY2uhwDxvWkd2PSzifTQROp rIu0XLMVwkvQ7tupfdBf2PTWlbS/0aE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687875582; a=rsa-sha256; cv=none; b=nu/cfpxPWrSJOzKu3XjR6/RB2tqx/saTK2Fs0sP5li4JTPmGAgiUL2JfsvABBohR4rIZmh fzZS/aitV+DSWQ+uLbLKm06m/AYAj/xIEfmSXmtzT8A1VJzLGK9FBvSyvqD0UhM/EDTJYq 7DZyFu8M0WvCAiDtbQUBvLApWIhNIT0= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=e2yOo3hq; spf=pass (imf16.hostedemail.com: domain of jlayton@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=jlayton@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1687875581; 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=Kg0oEjdzgulDO0g4qNXV/6g4eD+pg1i9NjIeehDQq64=; b=e2yOo3hqAlyhgFB5lV7zWQlLRerliFPucolbQ3j1fzRYn40/3BmQZ5rr2hF73QyM9oWdeL laONGVeHKpvmQq3+JBvg9K3O+tt/0u6ezj5AOYbAVJJjyGhz+hKClmJ8oeL6GKPbjWqxg1 O9wt6iF/aHlJsE8htAcVXPIc3eR2/F8= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-160-4Fg-hTQoPtWGeXfY8N-sRg-1; Tue, 27 Jun 2023 10:19:27 -0400 X-MC-Unique: 4Fg-hTQoPtWGeXfY8N-sRg-1 Received: by mail-qt1-f197.google.com with SMTP id d75a77b69052e-3f9e616e25dso68703971cf.0 for ; Tue, 27 Jun 2023 07:19:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687875553; x=1690467553; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Kg0oEjdzgulDO0g4qNXV/6g4eD+pg1i9NjIeehDQq64=; b=QbC1ncLUcLCivz+nm0vPPacSdQUc0joa/QZttdG8pBpCdUnfJQ4xEyLYRaQUjeuqic NOIy9qfzfr4TyuOXecBisa0ulmofN729+RvAamdXV61JTvlusRzYoZ6aFrRdsyLrl83d O3l7QcQiezhj0/94/Wgi+zjBJAFLXjBqyR/1jhlIPw5CwGg1KqKV7KN4dFpZfnwe3Nrm tvPN8s87mtgtkeo7psy5fsZcTz4kV/0UhbpwMqJjGKnNI/a+a8lY5Qx69+hwDyXUN8Fn /bUvHCXQ5fNn4IYFmis3tOa60/zPTnjbI1/LCWR28+YA3E+5OVyYswe10RXy1uNQgkGv lB4Q== X-Gm-Message-State: AC+VfDzT414ZkUE74wq7rRs0lV3qN64TRRzesOFocvQZrHy3EVqNUOSN l/JVZXpti9yL6ktYEBx8ak0uA/oMSc/QsJBAgTvC6LQQxMLn71SOU2ONbxcZbyhU8HAOhP0s5g8 VAmwZXJnE4Xw= X-Received: by 2002:ac8:5bc3:0:b0:400:e685:d18e with SMTP id b3-20020ac85bc3000000b00400e685d18emr5925986qtb.18.1687875553779; Tue, 27 Jun 2023 07:19:13 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7lpD5xB80vFy0rAeUma2fEBWQkMNSdbbiNbmQVtpZ2sDyNJSkly2azhNWp7OqYIrjhGfeUQA== X-Received: by 2002:ac8:5bc3:0:b0:400:e685:d18e with SMTP id b3-20020ac85bc3000000b00400e685d18emr5925964qtb.18.1687875553459; Tue, 27 Jun 2023 07:19:13 -0700 (PDT) Received: from [192.168.1.3] (68-20-15-154.lightspeed.rlghnc.sbcglobal.net. [68.20.15.154]) by smtp.gmail.com with ESMTPSA id fw15-20020a05622a4a8f00b00400a5ca26fesm2962405qtb.2.2023.06.27.07.19.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Jun 2023 07:19:13 -0700 (PDT) Message-ID: <90095816f5a57869af322b2be630bb21235e21bb.camel@redhat.com> Subject: Re: [PATCH v4 1/3] libfs: Add directory operations for stable offsets From: Jeff Layton To: Chuck Lever III , Christian Brauner Cc: Christoph Hellwig , Chuck Lever , Al Viro , Hugh Dickins , Andrew Morton , linux-mm , "linux-fsdevel@vger.kernel.org" Date: Tue, 27 Jun 2023 10:19:12 -0400 In-Reply-To: <61C84AD6-EB8E-49D5-BDB1-F87D3D5558B7@oracle.com> References: <168780354647.2142.537463116658872680.stgit@manet.1015granger.net> <168780368739.2142.1909222585425739373.stgit@manet.1015granger.net> <20230627-drastisch-wiegt-8d2aba4e5a0d@brauner> <61C84AD6-EB8E-49D5-BDB1-F87D3D5558B7@oracle.com> User-Agent: Evolution 3.48.3 (3.48.3-1.fc38) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 0E4EF180022 X-Rspam-User: X-Stat-Signature: agfiqas8ocmbmo6rr9tnzkcmumfp1ryw X-Rspamd-Server: rspam03 X-HE-Tag: 1687875581-469431 X-HE-Meta: U2FsdGVkX1/c5CyKndItEuXbdK2QVbGuEfdkkoIMx1Dd2T2Jj46Q6k9/Aw7BPYvsG3lM7cBqt1R9rpWqhTn66EIc/VOnGErEKDOdOuul6Yr2VK8DLQiimWXDyHrJ2rp/n17PAe+Ya5rXICbATuFggoEGbyi4GfimaGPFWcXNF3y/r9htwQe2gu/9T0NmRM+M3RrFMHAIkieIrHOhnpK2IfbSWI5U/RVASZV/pp9TYKnEWjdof2Kv4NdMlMH6BhDA3KoQuyrUdCEsTTgESTIQTqyQSXvnQLyVzZ8stDxVLZTnBu1uNRIIMuvNJbq+KKycCX34dN7VSD+YHrKRadrtgH6Q6pUbJbL2osgJVYHIhn5gt9CjXiy3E+ZoL8kUAQn7WhuAIAaNMOG7iH5y9wasRJiPUGqPqGRbxVSow8hoIfYV3cAQOIifJTy4KGwTeFuPMyhpecRnqKKY5E2lSKzRbShHNMgtS03dqiW+BgYQiu2jh3lZ3Te1FpZDLw6/txN6KjmXvZQQ6U+AFP5wxukpDv44PZ0tq0+ETX4Xv1PwY0Waewf/4Oa38AStEKjCuWAnroKoantuXpA/FHLoqNvimWkmaSN9bUIKI4kJjvgddCx2jUw7bEOpp1P5F3XjsvvT2P7hp/hgcQ+RwDRQEswK6a2VnB/rhh+ToB9DuFPzx0QkHGVTRSacVCH5cABLeLDStUIGFi9oEvAynTZsZAW7Z8R7K4hvxRlNw9TZb9poHKq7NeH2iMZlzo6UU1no+N+FkDE7PCLT83qzB7I5puz4qaNZZUNc5y8WFOMQdCXo1cb/5/XzXDkiqYbsbB/8sDXGJJNHB2aO2fLPXqzqRNBOloYC4y3kWPxxW34wPacqeTJkP1jzceXh6dIkqo/pdY6QS/IQHVQ4hW7Cx3+xMYet0gsvftAlMtx6xttv3yWdsaqLMm/ilhHJgVdYDIActJoDX4syvlU5Xs6rFaLg2sU j/pQlbA7 0ch8bV/o2wnqqyeiKQB/XCNPVZlpD+feomX5eaAFLbxuLx3etPWyRKQX5UbFWNGPw5hDbyn4iIP8c958Fxhb+N5srt2eFA27tJCnxasWx9AAjWcXTLdpXVBjvkO37dE6aRVlsg7y7CKE7FBcFRz6tzzGP8zDpyHb5+W8xd4bM9nZD+5W0Sf0pcrJGub0mDwK4TUVCotk6smqU77ceJR5/7Vqenmg4BIO02yRceQBb3iDSV2LLhrRRiXoq1kMCLdKd3b++s8pMjrmvA3Vobv9XY6/BT+KdXOE7yRUQ6zYMpShjHxu+lJzRnbpaCA53fPd3+79ZQUq+/Dm44qCroHdqb+j1IbHbHUU11Z3Elc002nx13TxbWwjcpGgrJOK3RlIOtu0x/VBws5ar+kzYt/G2UofSz0tJzgJIDJXnf3qh1SyyaOt2OudQ5u6wC2Zo6P1rzTOp1coKzI+T7gjcrRy/t9IR4NDtnz24GwmB8BHUjVXoUjs= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, 2023-06-27 at 14:04 +0000, Chuck Lever III wrote: >=20 > > On Jun 27, 2023, at 4:52 AM, Christian Brauner wro= te: > >=20 > > On Mon, Jun 26, 2023 at 11:44:15PM -0700, Christoph Hellwig wrote: > > > > + * @dir: parent directory to be initialized > > > > + * > > > > + */ > > > > +void stable_offset_init(struct inode *dir) > > > > +{ > > > > + xa_init_flags(&dir->i_doff_map, XA_FLAGS_ALLOC1); > > > > + dir->i_next_offset =3D 0; > > > > +} > > > > +EXPORT_SYMBOL(stable_offset_init); > > >=20 > > > If this is exported I'd much prefer a EXPORT_SYMBOL_GPL. But the onl= y > > > user so far is shmfs, which can't be modular anyway, so I think we ca= n > > > drop the exports. > > >=20 > > > > --- a/include/linux/dcache.h > > > > +++ b/include/linux/dcache.h > > > > @@ -96,6 +96,7 @@ struct dentry { > > > > struct super_block *d_sb; /* The root of the dentry tree */ > > > > unsigned long d_time; /* used by d_revalidate */ > > > > void *d_fsdata; /* fs-specific data */ > > > > + u32 d_offset; /* directory offset in parent */ > > > >=20 > > > > union { > > > > struct list_head d_lru; /* LRU list */ > > > > diff --git a/include/linux/fs.h b/include/linux/fs.h > > > > index 133f0640fb24..3fc2c04ed8ff 100644 > > > > --- a/include/linux/fs.h > > > > +++ b/include/linux/fs.h > > > > @@ -719,6 +719,10 @@ struct inode { > > > > #endif > > > >=20 > > > > void *i_private; /* fs or device private pointer */ > > > > + > > > > + /* simplefs stable directory offset tracking */ > > > > + struct xarray i_doff_map; > > > > + u32 i_next_offset; > > >=20 > > > We can't just increase the size of the dentry and inode for everyone > > > for something that doesn't make any sense for normal file systems. > > > This needs to move out into structures allocated by the file system > > > and embedded into or used as the private dentry/inode data. > >=20 > > I agree. I prefer if this could be done on a per filesystem basis as > > well. Especially since, this is currently only useful for a single > > filesystem. > >=20 > > We've tried to be very conservative in increasing inode and dentry size > > and we should continue with that. >=20 > I had thought we were going to adopt the stable offset mechanism > in more than just shmemfs. That's why we're putting it in libfs.c > after all. So this was not going to be "just for shmemfs" in the > long run. >=20 > That said, I can move the stable-offset-related inode fields back > into the shmemfs private inode struct, as it was in v2 of this > series. >=20 I too think that would be best. The libfs helpers will probably need to take an extra pointer to the relevant fields in the inode and dentry, but that's not too hard to do. > For d_offset, I was (ab)using the d_fsdata field by casting the > offset value as a pointer. That's kind of ugly. Any suggestions? >=20 >=20 Absolutely nothing wrong with interpreting that as an integer. It's a void * which means that anything that wants to dereference it better know what it is ahead of time anyway. --=20 Jeff Layton