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 57C7FC4332F for ; Tue, 31 Oct 2023 12:22:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A34A56B02ED; Tue, 31 Oct 2023 08:22:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9E4486B02EF; Tue, 31 Oct 2023 08:22:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8AC276B02F0; Tue, 31 Oct 2023 08:22:06 -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 7AE6B6B02ED for ; Tue, 31 Oct 2023 08:22:06 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 3CB70C0C23 for ; Tue, 31 Oct 2023 12:22:06 +0000 (UTC) X-FDA: 81405668652.29.253A775 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf04.hostedemail.com (Postfix) with ESMTP id DD12140027 for ; Tue, 31 Oct 2023 12:22:03 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=stIqHE18; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=ezvTsNdn; dmarc=none; spf=pass (imf04.hostedemail.com: domain of jack@suse.cz designates 195.135.220.29 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=1698754924; 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=LxFJRcgKBrTkwCYk/XtrM2vfD36eMy9uV2KLQkafOhY=; b=7fAbiGqVdbCUpULdCSjTdwUAOVB4FPVVz4WdUnJFua92Ew/1LoOPT4g6TbBfYVwzdkT1OZ CaEMf+1lmaZ5lZEZsP05uTOenrlU5SN9VTUdwdvy9QijiE+HvmsGBTbcEAIYupni7TlnyH /g4Ze7PCNMrR/fHXWtzmCDKOiYVggsI= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=stIqHE18; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=ezvTsNdn; dmarc=none; spf=pass (imf04.hostedemail.com: domain of jack@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=jack@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698754924; a=rsa-sha256; cv=none; b=HyeLF64fySAPMxudIt1pKEuAAEYUBXEC5OsgPMee7LCAFc0e5dxKFj35R1s2lfhlEqax3r NtjoFhDfnYjSvo1itIrNE+QbR6zDGJvV9JWEfj2M2JGlwOmak2YzPVhaalZyo+trnlXgby cINOUg10ZKyFGxtfYQsED8IV0ZVJaLk= 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-out2.suse.de (Postfix) with ESMTPS id 9FB961F38C; Tue, 31 Oct 2023 12:22:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1698754921; 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=LxFJRcgKBrTkwCYk/XtrM2vfD36eMy9uV2KLQkafOhY=; b=stIqHE18hi2qK54I3U59vf2hwUprwpecHKfDAQl0BfZhfY9q7vOh7VQOvfyRIjXKcuCKic KzxtNU5bDMp3XfdhMrN/PHoUj5JOtUvbLJw1Z1SqneYw14oLKXB5dXYyn7z9vA2N6wH7ST 4OCFQZPjOT/CJctCbnuDY/fSgPBEEfM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1698754921; 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=LxFJRcgKBrTkwCYk/XtrM2vfD36eMy9uV2KLQkafOhY=; b=ezvTsNdnRqRV9+SjqugsQVNOwztieZlM3AEVPM4DYQWa5mL9YeU3DWOSCLoXuxS8MGnhK2 d4woXKVGLv2zv/CQ== 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 8BBDD1391B; Tue, 31 Oct 2023 12:22:01 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id dhoQImnxQGV9SgAAMHmgww (envelope-from ); Tue, 31 Oct 2023 12:22:01 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id 1A429A06E5; Tue, 31 Oct 2023 13:22:01 +0100 (CET) Date: Tue, 31 Oct 2023 13:22:01 +0100 From: Jan Kara To: Jeff Layton Cc: Dave Chinner , 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: <20231031122201.kmxzttzfbearu6iu@quack3> References: <2ef9ac6180e47bc9cc8edef20648a000367c4ed2.camel@kernel.org> <6df5ea54463526a3d898ed2bd8a005166caa9381.camel@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: DD12140027 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 37z5w3po6y9u6znjhwtr96x47zkb1oyt X-HE-Tag: 1698754923-343666 X-HE-Meta: U2FsdGVkX19jYr9++TIrU4UzgAOOsygIPUQRtQxGgdf3fU7vGg+qD6ot8yNgWFRb/xSJKKwDbeIQyRQSc3ydrLQn5gOFkM0T1go661uRpWJVb55eqlLR9fHepaXrLXGIOqyLWaaPQv/0SX/sjTcWeLBUaOu6tRq1gS5TqHJklo3tuHCNSQKt20iDbsAtA5/Qyd8qAEcM35ImJH0b/lvOhQMErmdNAmLKcXBaog+yNK0tfYgMqfjwn6IgNM3UT5XOrdFUP0EGQd0u4zec+5KmLU3+1JmbbkzfILz/MpEmD0qDEpFFcAeFR1V57iPlj7suHt5EJOyt3wHo2+T/YYPhcXVP+pqHtmCJvoulNAoJ5hDDZ8M6EoJ91HSDElMvuzZmKI+IGUH1I7ca9jLXf2CltdM+AUSzjuuOfGibIDuiRDgdmzqwGPVpp1GCWjZn8s9ZUjaAHft0iEmesKGsvAxpPeW8v2hP/CXyjV5uz86K1kZHXxkgIXAxnbAHRiMuYtsr8lDE9hcxO1MKwUlRJGhnk8daAPRzGlg0xHCplJWYXTl3VySJ18mf//z34YJNBa50oGl2x4buS7lHhdK54mmDVRY1Cpi9ipuNdp7oQNC6Cgr9uq4OoI4EeAOQMXgzggdMwHKmjj8KgZajE+VqhGwWZ4nIcmBN0CbWNOi8cz8xmzG+tHX8Jh6es4qku35FeACE0HQsQrKHuhLVSV5Xnyq/+vcwdWzAjF2Xdz0t4qUMATF15JFtnavFOX9/A5W/8GeERwnEXuqkrwQFkcxfJy7sR/9PpjesGjbaB2/RoN/vcPg8I1Lwhvt0JkTt1QJayHdNXzDEpr6eXbtckyZps/5b8gqxMXoj6qMUGcEjhZ2scnWk1/l4cD5w82HHAQzWbczPpsNHXbYsBG0GZGNNXFDPWyfx5FpRr3FluiK+9st3fAsj7X0KDEsD+rt1CQX6AOq9jnTeFi4V8raM2tg/xfh XVs1Ulc+ UMKPSCAiCfb7+iGMP6/kK3JHt66vXlcqHX4Kh3XYxuHOsJV+If2u3WRTSt8FvYsagk1/0sKqMIdNIMg+vDbVTnKZZnx8TwgqSgcd0g3yIc0YsZ5xajfx9Xl1va6madFq2/FX0Fzd4+hOPJVC+6Kwj3GUjwLUso/tiX5hz3bGPvznEAUnqy8BYrIVjIYY0vlQEYM6+AHI7jBl0FEf1ntTiMYo/Wz0+tVPJj4kFTtUIzIcY9PVqu72athK6ORmoBRMgLVy8ad7cjWFKn9a9f6V/5EItWR/evfl0B6VcZ8NGJPmQSUOCuY2PClURhNmW2RVBQdIR 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 Tue 31-10-23 07:04:53, Jeff Layton wrote: > On Tue, 2023-10-31 at 09:37 +1100, Dave Chinner wrote: > > I have suggested mechanisms for using masked off bits of timestamps > > to encode sub-timestamp granularity change counts and keep them > > invisible to userspace and then not using i_version at all for XFS. > > This avoids all the problems that the multi-grain timestamp > > infrastructure exposed due to variable granularity of user visible > > timestamps and ordering across inodes with different granularity. > > This is potentially a general solution, too. > > I don't really understand this at all, but trying to do anything with > fine-grained timestamps will just run into a lot of the same problems we > hit with the multigrain work. If you still see this as a path forward, > maybe you can describe it more detail? Dave explained a bit more details here [1] like: Another options is for XFS to play it's own internal tricks with [cm]time granularity and turn off i_version. e.g. limit external timestamp visibility to 1us and use the remaining dozen bits of the ns field to hold a change counter for updates within a single coarse timer tick. This guarantees the timestamp changes within a coarse tick for the purposes of change detection, but we don't expose those bits to applications so applications that compare timestamps across inodes won't get things back to front like was happening with the multi-grain timestamps.... - So as far as I understand Dave wants to effectively persist counter in low bits of ctime and expose ctime+counter as its change cookie. I guess that could work and what makes the complexity manageable compared to full multigrain timestamps is the fact that we have one filesystem, one on-disk format etc. The only slight trouble could be that if we previously handed out something in low bits of ctime for XFS, we need to keep handing the same thing out until the inode changes (i.e., no rounding until the moment inode changes) as the old timestamp could be stored somewhere externally and compared. Honza [1] https://lore.kernel.org/all/ZTjMRRqmlJ+fTys2@dread.disaster.area/ -- Jan Kara SUSE Labs, CR