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 BD02FCE79D0 for ; Wed, 20 Sep 2023 12:48:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 39ED16B014B; Wed, 20 Sep 2023 08:48:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 34EC76B014C; Wed, 20 Sep 2023 08:48:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1EF986B014E; Wed, 20 Sep 2023 08:48:29 -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 109776B014B for ; Wed, 20 Sep 2023 08:48:29 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id CEBC0B3E12 for ; Wed, 20 Sep 2023 12:48:28 +0000 (UTC) X-FDA: 81256954296.07.F4FBDF5 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf29.hostedemail.com (Postfix) with ESMTP id 9189B120021 for ; Wed, 20 Sep 2023 12:48:26 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=F7mgIban; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=ekUr1eju; spf=pass (imf29.hostedemail.com: domain of jack@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=jack@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695214107; 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=S4Cb2+aB7mfyt7b8CnMGxNhCI32rhMMOyFzUtOYeWkI=; b=N6Ms0zV6NcD0hXeOa9JMKpEfxvXwgIMaX7PgbZNwjhiaRicFsdxDWGcAha90UjDYNr4qjZ ZMs0yaZeebEFucU6l4obb+LMuisxxGTl3NKaYSChvQsrws+ZpU5MKd7wM0c2LggfpMb+Pc SBffINxdSFup0vvMVZCgQ5ePm8fdeMo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695214107; a=rsa-sha256; cv=none; b=aBfzjtmDakDL3y2Tnmsn+De7oTH3xfD5AE6YJC5cg/iWf/bIVjxFWzy8KRDMEOe6PFpniY ntlTWhRpfFD4tiWEjWA2IC+K0/d5mvok1PyOJcUzzP4pt1fY8huHuQne+VGKxdzO/uTcNB Ht3GCSCLp+YcVAKxxgTEXzc8x33pD/E= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=F7mgIban; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=ekUr1eju; spf=pass (imf29.hostedemail.com: domain of jack@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=jack@suse.cz; dmarc=none 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 6FD471F854; Wed, 20 Sep 2023 12:48:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1695214104; 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=S4Cb2+aB7mfyt7b8CnMGxNhCI32rhMMOyFzUtOYeWkI=; b=F7mgIbanJ66gmiZEnO9W56nZWxHlxkK7s6FOoSjoypnC5mKMR7KN4k+DpGXfgaj5VjGrIN M0WZKpREOaiHCVlfxV6kRat3Qsi7lPO5Z2V/s3ZDJoLypj4Zm8y+7h34PJ3ugAMCBOih8J +FrYu16LwC7uAnxqkcIerKEtN0dDPrI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1695214104; 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=S4Cb2+aB7mfyt7b8CnMGxNhCI32rhMMOyFzUtOYeWkI=; b=ekUr1ejuvPyxJth9da/nEkPHSmqGtFGO/4Uu+iGJvWuLB6F/9QQ+xqsl4Q0KgC4KgxQtPa Leco5xPA1ZhiWrBg== 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 5150913A64; Wed, 20 Sep 2023 12:48:24 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 4Cc/ExjqCmXZZgAAMHmgww (envelope-from ); Wed, 20 Sep 2023 12:48:24 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id CD6D5A077D; Wed, 20 Sep 2023 14:48:23 +0200 (CEST) Date: Wed, 20 Sep 2023 14:48:23 +0200 From: Jan Kara To: Jeff Layton Cc: Jan Kara , Christian Brauner , Bruno Haible , Xi Ruoyao , bug-gnulib@gnu.org, Alexander Viro , Eric Van Hensbergen , Latchesar Ionkov , Dominique Martinet , Christian Schoenebeck , David Howells , Marc Dionne , Chris Mason , Josef Bacik , David Sterba , Xiubo Li , Ilya Dryomov , Jan Harkes , coda@cs.cmu.edu, Tyler Hicks , Gao Xiang , Chao Yu , Yue Hu , Jeffle Xu , Namjae Jeon , Sungjong Seo , Jan Kara , Theodore Ts'o , Andreas Dilger , Jaegeuk Kim , OGAWA Hirofumi , Miklos Szeredi , Bo b Peterson , Andreas Gruenbacher , Greg Kroah-Hartman , Tejun Heo , Trond Myklebust , Anna Schumaker , Konstantin Komarov , Mark Fasheh , Joel Becker , Joseph Qi , Mike Marshall , Martin Brandenburg , Luis Chamberlain , Kees Cook , Iurii Zaikin , Steve French , Paulo Alcantara , Ronnie Sahlberg , Shyam Prasad N , Tom Talpey , Sergey Senozhatsky , Richard Weinberger , Hans de Goede , Hugh Dickins , Andrew Morton , Amir Goldstein , "Darrick J. Wong" , Benjamin Coddington , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, v9fs@lists.linux.dev, linux-afs@lists.infradead.org, linux-btrfs@vger.kernel.org, ceph-devel@vger.kernel.org, codalist@coda.cs.cmu.edu, ecryptfs@vger.kernel.org, linux-erofs@lists.ozlabs.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, cluster-devel@redhat.com, linux-nfs@vger.kernel.org, ntfs3@lists.linux.dev, ocfs2-devel@lists.linux.dev, devel@lists.orangefs.org, linux-cifs@vger.kernel.org, samba-technical@lists.samba.org, linux-mtd@lists.infradead.org, linux-mm@kvack.org, linux-unionfs@vger.kernel.org, linux-xfs@vger.kernel.org Subject: Re: [PATCH v7 12/13] ext4: switch to multigrain timestamps Message-ID: <20230920124823.ghl6crb5sh4x2pmt@quack3> References: <20230807-mgctime-v7-0-d1dec143a704@kernel.org> <20230919110457.7fnmzo4nqsi43yqq@quack3> <1f29102c09c60661758c5376018eac43f774c462.camel@kernel.org> <4511209.uG2h0Jr0uP@nimes> <08b5c6fd3b08b87fa564bb562d89381dd4e05b6a.camel@kernel.org> <20230920-leerung-krokodil-52ec6cb44707@brauner> <20230920101731.ym6pahcvkl57guto@quack3> <317d84b1b909b6c6519a2406fcb302ce22dafa41.camel@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <317d84b1b909b6c6519a2406fcb302ce22dafa41.camel@kernel.org> X-Rspamd-Queue-Id: 9189B120021 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: obeufwij6h9ku4s9yp1uoh7wbgwmct3y X-HE-Tag: 1695214106-947282 X-HE-Meta: U2FsdGVkX19niu7JazoR5jHhmWRYM3dkcR/E29u9id65lh3OUeMHjbEr3mhtIp4icw+nSIp/OwNxUIPZhS7k/gs1wnEOwU/fsdBbLbiqabexh8qtusr/kxqVbm4TZjOSzcwektW43jk9o+l85ziGim+terOAxgHERWRDTsZK3L36e3fZWk/LDyVlQoSggg6itKtTI+3H4HxJqwFST0At5/DG/MrYnvSUXF2CFx4q+I/G7HfyC6PcukqHAIoWiIDspXzoL0S3GEDAbmOGbtKFb2zkZhMZD9jp2yTnzZrdSrkty6C0kNnhYg2jh/NPm9rpW0nCtppmXMCUxvIkViGJNR9vOZREM3EYCrexV/Z45KES1qKTVdDUKYOIrrzQLw0iW4Y9858ExsjSv5M5v13a+A2Hu6QNwVnEtscab4lRpOBzEbzpDTb4vZggA+5w1P1kotyl+kw/xqsKP3V4DRvK+bRP7YaWumrlI47xJKhGqWT9QLlLLTtl8z09IujIIpex8ZYyAiV8qlRaYI+Etr7W0RGpPCmu/vUylGzURhrzwCACiIyY7STx201+DCxK1kKb59ASNf76mIwCNjBwdcXJplqRxhD+1hs0aGdHvxGGp3u6AHcHPDpIsjXez3gkFoJfSCDTF9jquafC4WTdA+pJxcWNAFEOvLkFerewofiCm1IgN8FChme0LYOSJPxmRdh5ShVUb37imE9qOIP/RZRILZyGhWEBovQi8/UTlQTCdfbEhk6WOZYZvooRGd7Z4PSExaYHg/v21ba/Q0h5nkEuEZ8RcbNo3OgHySNvgdYaeoiakCX4j4bScpWk6OBgN7hWfzbWmkwpbyM8W5WNa4U9oJgYyfFSASEpN7TTecmfojNuuPDzfw2IstG62wPlXAJ54k71MzN3GiNZjLIaMNZnPShOkSRH6zrevfpJUyNFY8kN3FLS0qtv6PCLIkTT2s9cXaPBYzE2w28fk6SjUqY DAmZWTVn FdcUXfVBs+Eix8KnsAflxJBTsVqVibG9+pFTHfbQecdddMqmkYmXEuDF1DbAOVDosHRNSXE5td//49yAw/mvOQ6mmdIAjWe+alUcS1NGuBP1xEZnVZhgS53roUh1L4g+pOO2CuS7IBTk6AdfuK3FVpOnATmqnRfIz4gH9RHx6RH4dyGJFTKYaLWDOnso8cpugsL5h2PBn8wE7/BFtjsE8vAJ0cpRFSe+W+ZbjGaoORc5pLV3uzxuXBxeSWtxPKF1EiM8M 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 Wed 20-09-23 06:35:18, Jeff Layton wrote: > On Wed, 2023-09-20 at 12:17 +0200, Jan Kara wrote: > > If I were a sysadmin, I'd rather opt for something like > > finegrained timestamps + lazytime (if I needed the finegrained timestamps > > functionality). That should avoid the IO overhead of finegrained timestamps > > as well and I'd know I can have problems with timestamps only after a > > system crash. > > > I've just got another idea how we could solve the problem: Couldn't we > > always just report coarsegrained timestamp to userspace and provide access > > to finegrained value only to NFS which should know what it's doing? > > > > I think that'd be hard. First of all, where would we store the second > timestamp? We can't just truncate the fine-grained ones to come up with > a coarse-grained one. It might also be confusing having nfsd and local > filesystems present different attributes. So what I had in mind (and I definitely miss all the NFS intricacies so the idea may be bogus) was that inode->i_ctime would be maintained exactly as is now. There will be new (kernel internal at least for now) STATX flag STATX_MULTIGRAIN_TS. fill_mg_cmtime() will return timestamp truncated to sb->s_time_gran unless STATX_MULTIGRAIN_TS is set. Hence unless you set STATX_MULTIGRAIN_TS, there is no difference in the returned timestamps compared to the state before multigrain timestamps were introduced. With STATX_MULTIGRAIN_TS we return full precision timestamp as stored in the inode. Then NFS in fh_fill_pre_attrs() and fh_fill_post_attrs() needs to make sure STATX_MULTIGRAIN_TS is set when calling vfs_getattr() to get multigrain time. I agree nfsd may now be presenting slightly different timestamps than user is able to see with stat(2) directly on the filesystem. But is that a problem? Essentially it is a similar solution as the mgtime mount option but now sysadmin doesn't have to decide on filesystem mount how to report timestamps but the stat caller knowingly opts into possibly inconsistent (among files) but high precision timestamps. And in the particular NFS usecase where stat is called all the time anyway, timestamps will likely even be consistent among files. Honza -- Jan Kara SUSE Labs, CR