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 D674AC4167D for ; Wed, 1 Nov 2023 10:16:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 552D08D0037; Wed, 1 Nov 2023 06:16:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 501BD8D0001; Wed, 1 Nov 2023 06:16:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3A2458D0037; Wed, 1 Nov 2023 06:16:53 -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 2A5A58D0001 for ; Wed, 1 Nov 2023 06:16:53 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id ECB6C120C60 for ; Wed, 1 Nov 2023 10:16:52 +0000 (UTC) X-FDA: 81408981864.18.1D5A1D3 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf20.hostedemail.com (Postfix) with ESMTP id CE6941C000F for ; Wed, 1 Nov 2023 10:16:50 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=cIDBQeCe; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=mvEEW889; dmarc=none; spf=pass (imf20.hostedemail.com: domain of jack@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=jack@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698833811; a=rsa-sha256; cv=none; b=GAzVqdkNkNIGyZR362tTznqsZQaf6wrSXuGeaQIRR+2P4NSVb4Y1ZFhN0RX/nD7+A2/ScF x0DW2flVPYcPnJnbd5jUTxUXHHcN5X8Wanq8A9Tcv7mJ+cXLHTYWaLT+dzs7t7tuHXFRl8 rWNX6GKPzjRnhVysf/J9mMbqDOrPAeY= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=cIDBQeCe; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=mvEEW889; dmarc=none; spf=pass (imf20.hostedemail.com: domain of jack@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=jack@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698833811; 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=CFpkczKLmbO7DBmC+KuusmYf1M81/8uEj5OEO9u0an8=; b=WvF7gJbZfuS2lOGkEF1XmokS6fa/Q2OmxbwRoBv6fMXQuPJZf/dr0A4Xpd7TpQ1HItl08F QfHSDg6kflEYl9MHUHZQuSjUDhXiheLznUGhfERCpeTb6wTqOFPvnSwsTpSJbO8Upwz1Fu EFxdkex0zk/XZNVqbA1evFw6ULxIjd0= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 80D4E21A62; Wed, 1 Nov 2023 10:16:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1698833809; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=CFpkczKLmbO7DBmC+KuusmYf1M81/8uEj5OEO9u0an8=; b=cIDBQeCeT6F/rRtPtuWsaxhbXCw/Oy8Nd3TyqIdVXqkKWHuejYiCFHWbJG36hEldNK/gE3 PmAIxp18ujdwD778pBZ/fbbmaGxjbOGZeg065cemuCDzPnGNMI05uyPZkJArv7AoMBGwNW DccVThknuJ0/4feaYznjvdWoDckhhmY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1698833809; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=CFpkczKLmbO7DBmC+KuusmYf1M81/8uEj5OEO9u0an8=; b=mvEEW889xoYvMMVwNIK0/VQCeU1UNx7tGnXGVlAFU0jWGpNvK1Hq0sOak6HpTutwkrFEmF VSu8elpoFbhhjyDA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 6E0F51348D; Wed, 1 Nov 2023 10:16:49 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id +FrRGpElQmX8GwAAMHmgww (envelope-from ); Wed, 01 Nov 2023 10:16:49 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id EF5D5A06E3; Wed, 1 Nov 2023 11:16:48 +0100 (CET) Date: Wed, 1 Nov 2023 11:16:48 +0100 From: Jan Kara To: Dave Chinner Cc: Jeff Layton , Amir Goldstein , Linus Torvalds , Kent Overstreet , Christian Brauner , Alexander Viro , John Stultz , Thomas Gleixner , Stephen Boyd , Chandan Babu R , "Darrick J. Wong" , Theodore Ts'o , Andreas Dilger , Chris Mason , Josef Bacik , David Sterba , Hugh Dickins , Andrew Morton , Jan Kara , David Howells , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-mm@kvack.org, linux-nfs@vger.kernel.org Subject: Re: [PATCH RFC 2/9] timekeeping: new interfaces for multigrain timestamp handing Message-ID: <20231101101648.zjloqo5su6bbxzff@quack3> References: <2ef9ac6180e47bc9cc8edef20648a000367c4ed2.camel@kernel.org> <6df5ea54463526a3d898ed2bd8a005166caa9381.camel@kernel.org> <3d6a4c21626e6bbb86761a6d39e0fafaf30a4a4d.camel@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: CE6941C000F X-Stat-Signature: on7to1s5rr6k6xr3au5o4cgfggjk1twg X-HE-Tag: 1698833810-586096 X-HE-Meta: U2FsdGVkX19oD2vyBdyfsw3Z210TB0MwYAnFQA/l+lteT8wXYhpt/dAeGAPpA1LB33GTwLzT9WnwOPsGF8HN+nZ3yaZwLnkGulAEB8HmG6gL7voxab+oAzzyymtP9tkWyNhrb5RuVGSQWCKEmDhpm3aAIi2WIK0TQ3tW5qIxEGD6rWNDRpRTj5lL1jOfoSpEFYGlmY74X5UvKrYq1Qn0+YMAxKh+V9NXpHS/8Aqxbv8RaJRdIsywIMKt0mIoNkDsw/pcXlW7ksOiBCEyUA82JcC14ViQbK/d4xiXfhoPWV1vMoTk5VWcUEBE4L/ieCLhyc09JbHHoz9f+HENejYdIKCKX3z+tI049dikhNHSi2DqUAEZnhZPrqHGU0CRCLF/nxOP65DS134p8Je6uyrc0FnCNEuzDg5GSgHGW8V1N4/xO8usJiK2h8gT4QA/mDAhP+kuieutoawW9p4cZnEViA0ueF9mpiQJFoEOlBEbp0O6PrEAXAcZFs0o7fnVus3Yew2BFxUSKau7biuJI7Bdoye/hnF1VpfyC+onMdvEUkfKpy3erLjBvqjccVCtY2w8CXySymeeJH74xBkN2Y0BadtMt1vGRsdrlxWwdIBj5eZNb4AYsHt9h15NnFB6msajtduYDyhEqMzyk4sQ+8vd8YzxsLvcRj5bJr/3NU0TsRbRHjZ0OC5aLk6hYym0DBbeYdZSbHDSqf4vGV9NhI463kjNLAfj+cWU4oZnZnACSU4g3aUizBPSXbGJKRluA+Qx7bBhbKkiVN7E/wg7oC60wOe8+2ToGMYlU36feSqmtW7Sj0JrNu6DyIIFOE7Uurc7N78IUvCkHnZdn/agrKIKazrVWGQ8C6sjhmLxTRl75UYPufcQte2dszK0RYHlJA+ohu64MYGsOuA8fBrj8uo1IHQ/Whghq6qXEwk26LAxXOfwzeTCnHujCGFalyYIOCvDnc62goKZupBCnWIWFZQ GYbMNDVW nKW01ZB0Bl9hWs8/wWfr2sPGrwdSOvkoRq8M1LIWLdcgcjQihExKWEzZpB3Ml5lB+VwlPmiOm6HqnPgtO4irkult3jZDSybImtqdfpGNPH35aujgJjLPZmpsHsJNa1PWB/jCy7tqwfdyIOc5xYVaY60uYTg4PCV365iyC1pyIskjNer46MPwu439LXTCD4frwXpVU8BHjKIL+LzoYpyp+ZEHR+I3jegmY+3IgLsJFtpFwRBe24RFyEZFIHKWaN6507Px7 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: List-Subscribe: List-Unsubscribe: On Wed 01-11-23 08:57:09, Dave Chinner wrote: > 5. When-ever the inode is persisted, the timestamp is copied to the > on-disk structure and the current change counter is folded in. > > This means the on-disk structure always contains the latest > change attribute that has been persisted, just like we > currently do with i_version now. > > 6. When-ever we read the inode off disk, we split the change counter > from the timestamp and update the appropriate internal structures > with this information. > > This ensures that the VFS and userspace never see the change > counter implementation in the inode timestamps. OK, but is this compatible with the current XFS behavior? AFAICS currently XFS sets sb->s_time_gran to 1 so timestamps currently stored on disk will have some mostly random garbage in low bits of the ctime. Now if you look at such inode with a kernel using this new scheme, stat(2) will report ctime with low bits zeroed-out so if the ctime fetched in the old kernel was stored in some external database and compared to the newly fetched ctime, it will appear that ctime has gone backwards... Maybe we don't care but it is a user visible change that can potentially confuse something. Honza -- Jan Kara SUSE Labs, CR