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 9F474EB64D8 for ; Wed, 14 Jun 2023 06:29:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 28AB26B0074; Wed, 14 Jun 2023 02:29:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 23AF88E0003; Wed, 14 Jun 2023 02:29:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 129A68E0002; Wed, 14 Jun 2023 02:29:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 03B906B0074 for ; Wed, 14 Jun 2023 02:29:42 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id C5E54A0158 for ; Wed, 14 Jun 2023 06:29:41 +0000 (UTC) X-FDA: 80900377362.01.313810B Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf24.hostedemail.com (Postfix) with ESMTP id 12C4718001F for ; Wed, 14 Jun 2023 06:29:39 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=XnX11RI9; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf24.hostedemail.com: domain of brauner@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=brauner@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686724180; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=WhRg7AS1rFppn5iIs8F60bd4ptNXmG1fNIigho91Fjw=; b=pZkiBJLSHaW6wsE6bWHX+cYL+vntsu4WqQ9wRogiWzeATOdRpeuqDkUy2OZEj6YdklEFsF 4UZpRzAlGNyfoLImurXAsDeMFcMi2akAfo/9hLxDWJ1Cv6hQl5pYxcFl0R9cxA95zqkml9 eK3I2ocRe9t/7nvjG4mUY1VElHSxEJQ= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=XnX11RI9; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf24.hostedemail.com: domain of brauner@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=brauner@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686724180; a=rsa-sha256; cv=none; b=rSDy5fwva6ZTZKO/lG2rNihdBkO+SuqJjTl959bYx6NNzYqFr0XfYE0OS3VUgfRdu+79CH KL+QxegRq5mc42JTD8rWW443Won9/kf8ISrBUnk5Kv9FVEc/xBgHmfkRbf1NFmIoYk3TFg MQBhUixp9fGvr95Mus9Z2PSNOpj3/jY= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id DF71D6356C; Wed, 14 Jun 2023 06:29:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5D9C5C433C8; Wed, 14 Jun 2023 06:29:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686724178; bh=XjFkOsOx183EvSiM4yPrENjUW2d5opZ5TvQfHk7+D2E=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XnX11RI911zmZAW2F67s3+Ymqh1WyrS9FAGLruYi0rzwQOXU1+S0hh65U7iPNXoq6 chqapxeFWuQPWe1xw5png9URTFBluyLfk4L59UjPan9xuJTRHK//t2Z5ie2yzGNTva qtQi48csnlK0bKeNPyWNQ7KX8SMFwBcnhVywwMAmbDknwoN451G2FPeFgN+O75pBm3 WtTXZEDZE2FCRdCej0zaWKFjud0zNmD8JJuXe2p307imyZZdCdixaF6gKTcbWD0OOt 9+GJw+FhGue1elde/UvtQ6Neflo/LSA/woAWF7Btga+5DatyoY4t6prX187y6cupLw qW86pY+AZP7aQ== Date: Wed, 14 Jun 2023 08:29:29 +0200 From: Christian Brauner To: Jeff Layton Cc: Jan Kara , Alexander Viro , "Darrick J. Wong" , Hugh Dickins , Andrew Morton , Dave Chinner , Chuck Lever , Amir Goldstein , David Howells , Neil Brown , Matthew Wilcox , Andreas Dilger , Theodore T'so , Chris Mason , Josef Bacik , David Sterba , Namjae Jeon , Steve French , Sergey Senozhatsky , Tom Talpey , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-mm@kvack.org, linux-nfs@vger.kernel.org, linux-cifs@vger.kernel.org Subject: Re: [PATCH v4 2/9] fs: add infrastructure for multigrain inode i_m/ctime Message-ID: <20230614-fanal-infamieren-b9c106e37b73@brauner> References: <20230518114742.128950-1-jlayton@kernel.org> <20230518114742.128950-3-jlayton@kernel.org> <20230523100240.mgeu4y46friv7hau@quack3> <20230523124606.bkkhwi6b67ieeygl@quack3> <11dc42c327c243ea1def211f352cb4fc38094cc0.camel@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <11dc42c327c243ea1def211f352cb4fc38094cc0.camel@kernel.org> X-Rspamd-Queue-Id: 12C4718001F X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 914tgbi3ts76rrzuo9aa6swcqi9msm7c X-HE-Tag: 1686724179-177032 X-HE-Meta: U2FsdGVkX1++k+5wF8ts3Lk/2FXdDBhYBgkt2Kg0xOFdIBzt9pUrSQKkG3Pl2+lbYu6yBD96yjraPm8G2hoiSv00+civ+Kd9pnPsM6DXKur2budKk7ZEiz4q6ITgSpJfyFPvHJA+aLwt289mgcIrJ6FH6xv5n3gf4dRYeR3Ii33JM1nQWMQC7VFKQWF9YBlBdCKx57UUcrIUtr3Ni4gGAo1OEc5CDqL6XljxpLZ6CN4+u/4huM4XToxouLCnkH0H9xS22kSQ8H3TrjDeT1aZcGDXjqMZEDlpOKpnPvn7j7GVc6QHp+K5dDTjSPlCnZAnbudTQ68CGTjEj9zql9reiyUE9ZBpmxFV1tXVyoIgAxINBrCxfyz+yUSMZg6GNy1dzJm9eG4OFmGdiFiTi5njPnzh57ASerm53RWcHrMQGhMYSeoDehD+aH1CJKN9Iw4jcZEIUVPcIlTvlyXSFgcz1fh0v6TV4sPUHFWvhQs+8MvcODdXihiuYVwWQo8v6n0wIloPCYQXbVpBYq5ssPLO7X2n+Ow5S6CD6vEWcX73nJuVZIQqT/UB6XpI4NqYIhzL/U6t/etgsPmjiK4Ti189nkGOOdWduqjytZzhHYikad46EZoDETGAPOJP5euFXPkd60g15UW2UeuUZc8RVeJMoCTV1NW/iPyOOl+Mnr3W3c9ZEO1JsKykFbNdHUo+25IxBml5dS1ILGItyXcSA+swiNe2wMSq0Q2tlLKTb2ERlGhmCUIxzwwWElu+VI0BvNJusiuZeBJ5KHuqZ/1L3AQyFcH96PsGnsZjJXaOWxzGXkiiNCZynvd0zIK6dDg3zk2/lz1aPyKqqoErkilkXg3tGZqGzffS3xifniNfV/m3FeX1WKOqnQtxgypbo4x3lqcAsAXYqCcuKgD6kqvaVnOmeWgcipzODgPwckQf7ipfQVcdCGwgRmGCOxRUAO2BOKs3d+1POeBXjWjHUcAU/R/ dkjJ+sJ/ 2unyQz6hGJTV7h9E+UDMIREeoL9aWgU3/48uWhlHg3gTqvz+ZqPoRyifE3L0vPqkaVbiRn5uSpSju0zOW2ilUFT0ODtlmL3xKn7F5rw1lSYVnXFRNEHzlBp5Ztgl+PvvsDNQwUyySoJp+TpvtON4W9MI3sn0DQwnj2EDkboFC93ohGY0i6vQvh/3dIkhMmX/6hKgsmisK9db/Oa8vyfdom0e3sfVRfKCutFmQzUmiIvYQbV6aJx3TQu2WOwkLjVwK63+a/pFO59vrexgTY44gLnZayF2BmU7glXmaYxLKOmv1/Ph5yCkb/ALZQu4zouTjcqGPK2LOFQ4flaz1CekO7AZGQF9VcVGWtWsh+Wre0gAa0aYUNfTKDeHSKU5LpO3knQyPxHrz/bjCFR8= 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, Jun 13, 2023 at 09:09:29AM -0400, Jeff Layton wrote: > On Tue, 2023-05-23 at 14:46 +0200, Jan Kara wrote: > > On Tue 23-05-23 06:40:08, Jeff Layton wrote: > > > On Tue, 2023-05-23 at 12:02 +0200, Jan Kara wrote: > > > > > > > > So there are two things I dislike about this series because I think they > > > > are fragile: > > > > > > > > 1) If we have a filesystem supporting multigrain ts and someone > > > > accidentally directly uses the value of inode->i_ctime, he can get bogus > > > > value (with QUERIED flag). This mistake is very easy to do. So I think we > > > > should rename i_ctime to something like __i_ctime and always use accessor > > > > function for it. > > > > > > > > > > We could do this, but it'll be quite invasive. We'd have to change any > > > place that touches i_ctime (and there are a lot of them), even on > > > filesystems that are not being converted. > > > > Yes, that's why I suggested Coccinelle to deal with this. > > > I've done the work to convert all of the accesses of i_ctime into > accessor functions in the kernel. The current state of it is here: > > > https://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git/commit/?h=ctime > > As expected, it touches a lot of code, all over the place. So far I have > most of the conversion in one giant patch, and I need to split it up > (probably per-subsystem). Yeah, you have time since it'll be v6.6 material. > > What's the best way to feed this change into mainline? Should I try to > get subsystem maintainers to pick these up, or are we better off feeding > this in via a separate branch? I would prefer if we send them all through the vfs tree since trickle down conversions are otherwise very painful and potentially very slow.