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 2D4B0C4332F for ; Wed, 1 Nov 2023 11:38:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 87D358D005F; Wed, 1 Nov 2023 07:38:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 803BB8D0001; Wed, 1 Nov 2023 07:38:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 67D318D005F; Wed, 1 Nov 2023 07:38:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 5060B8D0001 for ; Wed, 1 Nov 2023 07:38:57 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 15386140BFA for ; Wed, 1 Nov 2023 11:38:57 +0000 (UTC) X-FDA: 81409188714.26.2AA84F3 Received: from mail-yw1-f175.google.com (mail-yw1-f175.google.com [209.85.128.175]) by imf07.hostedemail.com (Postfix) with ESMTP id 58B8140015 for ; Wed, 1 Nov 2023 11:38:55 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=mSd1+ANM; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of amir73il@gmail.com designates 209.85.128.175 as permitted sender) smtp.mailfrom=amir73il@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698838735; a=rsa-sha256; cv=none; b=ND/M6U3WMWadiLmaWEiJUuXZZhE9xybGLQ4PhQ+lbqQsvhftNQp+J9gAe9ua4CDJAlGgDl M03tNMLAGi6ZQCnYGSZVfTELswb59ae3YZNLP+x72z1UfUhGBHUNkRhtYphsvVLyc/9OIp LNDBL73jUR/d97WUYvRvbtfW6EQ86mo= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=mSd1+ANM; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of amir73il@gmail.com designates 209.85.128.175 as permitted sender) smtp.mailfrom=amir73il@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698838735; 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=m59jZyxH1gZ4IkJNBzdNka8KVbsaoVT0nyeW9BoP3MY=; b=OlIM+t800h3KCwmElcBHt4mtWGcpXpkHCrbMkvz2l4ZMx9GGUQXmLJtuARbVCwiuWEEvZU pBRifes73+2W0NB/huvIMowIq/XRohiO1mEcnEVFervfFa83nHZQBMEFyNSWH6bXx9SZg2 WDg20mK8+gGHBGqexVjjSCfH/UcTQjI= Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-5b383b4184fso16909727b3.1 for ; Wed, 01 Nov 2023 04:38:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698838734; x=1699443534; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=m59jZyxH1gZ4IkJNBzdNka8KVbsaoVT0nyeW9BoP3MY=; b=mSd1+ANMOjP+obJtuPdtmWtB1EXCUNA7EXEirio9uqcyd3xXUfmolMFdPRyZfoOoVk oJVCq9drMaGiT8NnJMW5qjFiWd0liYCbcWx6I0v0LQtPSzNnSIas4JPmcGwIy/qJrX2T 33MOCpNKZCCJ+hn/nyaFZ90VedklUkFHcJjvr35Wk3fcfLxhUkWK/ssirUuBuudNiHtN BOwur70Ys6utCyclhNVUn47WFXi+KptEgNpYi2TBfXhMTN8BthLKNbd8sTAWj86nqIU6 Flgu8msW9xZsG1RBVQeQgqRRTKwgPGkR1bposgsyz9/IB08R9qkmaYrCzksn11Yebe4p 5KJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698838734; x=1699443534; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=m59jZyxH1gZ4IkJNBzdNka8KVbsaoVT0nyeW9BoP3MY=; b=g5Qa1fi+GLGT5aAuE8LvKv1Qsf4jMO9nen1xdTDPtxWELy0Kt4eUYLLTBZi9KkfprP AIeAtv2dcs41fMjjEjhOuOwXEOvYAZy+fs9J3YB8eL/LF+5xBDdwVYl+mvS5pBLCYqQW dn+h7qdlt7yT2jbQhzTE/XpFK47kW2/RZf4q63ofoiqUee7z1gXk9juJ0a+AsYZ1pUll /gd3ChSumnSdNtFq5xC6BdZxaV/xOs5fTkFDZC/1siJROWWeWtaUo2Ox/eM8Ysb7zcjQ jrnZXqGOz9oVKha6uIjttwGyYlKOqHohLKxoylwY1+Y7rUum23ReyuZmuSF2xbCzpVxE IxAg== X-Gm-Message-State: AOJu0YwNSC+EcVWkC77GXLZgJekNAlU0UJBh/5p4tf/io7HfjzFt6xwt /bIGaDkEUho+7GP/fgVMjL6xos5CSHXwPpKAJwg= X-Google-Smtp-Source: AGHT+IGPiQGs2flMchmrpUm3exXHwdHaIxqaR1nEgkE1E5+9YOWUy0Mc758PsX3a/8WhBl38xRZWvkoZHjkiwWqRbg8= X-Received: by 2002:a81:ae09:0:b0:5a7:dad7:61dd with SMTP id m9-20020a81ae09000000b005a7dad761ddmr15318204ywh.20.1698838734410; Wed, 01 Nov 2023 04:38:54 -0700 (PDT) MIME-Version: 1.0 References: <2ef9ac6180e47bc9cc8edef20648a000367c4ed2.camel@kernel.org> <6df5ea54463526a3d898ed2bd8a005166caa9381.camel@kernel.org> <3d6a4c21626e6bbb86761a6d39e0fafaf30a4a4d.camel@kernel.org> <20231101101648.zjloqo5su6bbxzff@quack3> In-Reply-To: <20231101101648.zjloqo5su6bbxzff@quack3> From: Amir Goldstein Date: Wed, 1 Nov 2023 13:38:41 +0200 Message-ID: Subject: Re: [PATCH RFC 2/9] timekeeping: new interfaces for multigrain timestamp handing To: Jan Kara Cc: Dave Chinner , Jeff Layton , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 58B8140015 X-Stat-Signature: cob3sy37fynnhzkugfzosf6bxxjnc4pr X-HE-Tag: 1698838735-587348 X-HE-Meta: U2FsdGVkX19+fDsugeR+LYROpuvSDAH6YFnth5vEWfZYbE0VHlC4nRqPTpMcGu/3xPoue2WrARLlpaHp20KbMyk48z4TAv1AmwMK0PxQiMPEZKs4VH2zzSoYYnPIN2QmJCk40RIKqlM7GKPjt4azzEEFt83HHAtD2lh1LskO8HLtdxl3IKpuvRWLBLqjG91cbDVNwFQk01hoUBhAr6Xju+oPcVj1BrHC45W3UNLMqrUVNscNdZAVLlxbcXqiNb8Gu4/OgM4kf1BRUNJMHDwOuc5a9Jwlp90pz9kryHFm1CzabjZJSSGm2NUPinqAmFNetIrTELDS1ZyC2F6HmH1z+XcwNmIFmBXKmb5CumU+LmlwSJrQxYtujoItexQn4jxnPjj1CEJc0/WxNM5ddzSuI5Fh5KkISxCjNYmCLt/jhwsOJ4aRUkn6FQjAAeFzKXgiFpIDLbYIsex876bOuAUjuMOBQiCKPUtS1JeU9FO51WEYRsxnbifTrSoWiwz2YDIyVHEwFJEV5t9n3Oq5FHJROwDcaw/HMPFlrIEsVG4MoRDclbXXoK2Rq2PDXf35k7B1l0S04ukNJhGqArZc9EMaW/ziNJG0DBW1Ut5ExOlDR7DBy55SvEg/k6b4D+pWggR/7K8yq03qoC/tRRJtQxhxTTVaSh8S7SCMj4K2XI8BK4OMGCB34a+IrdjHHrUOa6kwAbtU+6BllLxn2TflzvvfCbboIdosZ+Up24rE9YLIXsoPonBlCpOstevN1MkfkEX0i0IkdvC1cXqiFpQIt0TYNHdMbdw2gFRYvqpNDWSmpywy5EXDuVEBeZxJSkv14ooMeGfZ6lP7YovS8pQlLwTyMOzK2MLsifQqJ4XnsT9UQ+YEfQPQKmOUjT3xFdykDQPSs8bsQDNszcl5gKxSpayr1ODdSaZDEUT+rmy1DjJry4EJ+1b4Z0PJAM3OikhTZUMDgfjLbgka3OKRsZdARRO aSkWwRcx yUOZTXSCbihsFHtmFu+m8kecdA0U08WwSLqn6l1KpcLUAFoJDDA2jwQ8UGRtMXH2UUW1OOs5rXntWgskRKe6YnrfjKIsXv5TzM2ncDJoNeU+UGD34Zq9D8J1HPmHw6p6shNmQFvH7TvPpyVgeMR+xVTAB6xg6icVULDnQ4C5UPAERF9JjDYqz2HZFQe9VH8zlBsVNATEGnHbT7nX8ZKF6DmDDn95PkVVRMzjg57p2xUClWQmQ0B/Oi/UKetZC3I13h93rEOGQdcQKZB/Id1ImvYbR2Ocu97ii8ZLvw4+fnc7IgT3LRq8+e0bEN2//Bo8eEGoT/y3EdOl6acagJYYyFbTKaHACVGkGAghw 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, Nov 1, 2023 at 12:16=E2=80=AFPM Jan Kara wrote: > > 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 currentl= y > 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 i= s > a user visible change that can potentially confuse something. See xfs_inode_has_bigtime() and auto-upgrade of inode format in xfs_inode_item_precommit(). In the case of BIGTIME inode format, admin needs to opt-in to BIGTIME format conversion by setting an INCOMPAT_BIGTIME sb feature flag. I imagine that something similar (inode flag + sb flag) would need to be done for the versioned-timestamp, but I think that in that case, the feature flag could be RO_COMPAT - there is no harm in exposing made-up nsec lower bits if fs would be mounted read-only on an old kernel, is there? The same RO_COMPAT feature flag could also be used to determine s_time_gran, because IIUC, s_time_gran for timestamp updates is uniform across all inodes. I know that Dave said he wants to avoid changing on-disk format, but I am hoping that this well defined and backward compat with lazy upgrade, on-disk format change may be acceptable? Thanks, Amir.