Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp2322755pxb; Mon, 11 Jan 2021 06:55:09 -0800 (PST) X-Google-Smtp-Source: ABdhPJzm1cExML1aoS6by/rIgEnXbnNQA8kdFTDeYw+2s+M3havjehnqOXiFbav7WqMh6I5Fys9q X-Received: by 2002:a05:6402:b88:: with SMTP id cf8mr14903446edb.140.1610376909385; Mon, 11 Jan 2021 06:55:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610376909; cv=none; d=google.com; s=arc-20160816; b=y3iCJpYHE2FEjCAs1Q1GvPtWceLcMAKu0NDJCXXiidmEsSw4yCXx4mhJ840GSR5iVQ gJawEA1WOLbXf6Ggvs7lkJbIpyLJKKMs2MwD2oyluBRUnAzQDqgczYBeLivkhwdcxdpY n6VVsJuneLZubGocmralVAd2cURLikNFy+EEPqW2yt7W9CK93ui3QNKYKNVf4VNNL/6T ji51FDbPQ1vVr/ADt/2M+JgXoAx6OhAefF5YwcDkQ55j229nxVNx7R+RvBfLWOUhE4/+ iVrwjwxZDBzmQ8x5pQ5O5BJDsJhpjjNX84F1gQgLvuun5hdC+DQvbft6Fih3NPR1JUvq VyHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=wg2Yk05lN1euWviFtS1Vee4px5duVZOqbc8fT6EYB1M=; b=If+v7+27/63sNP6q0WKIQBVIXNMTauSTJvbzGJwNynMa5iuE1rpRjhAFVbLRKK/hJ4 oOV8o1FsIK/WPtcFmqzgjGwdeAGL8FHIP09o3JGv7u1FDTe7i92eigXKZz56qdjXlgoy ZIUSvSLv0V0pz9+Y9TZ/zpOcCGDhNx1QyjuS0pcqntlPzK4ayEAEuWQut+ndKW2vCs6u 6C26GFnYcWTKvK1o4d5q3bCnJXnN7tvAHfLWPCVVPDirlbTp0cgFckDZRsfnQmBJB7XO VoSTYASeCXydY18NEjYM0YiApnVBsd8+QZ0DQgC23Y1VSCSFzVQRwgdXv/MeK6+hDwCG Otgg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n18si6465937ejk.69.2021.01.11.06.54.45; Mon, 11 Jan 2021 06:55:09 -0800 (PST) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728443AbhAKOtj (ORCPT + 99 others); Mon, 11 Jan 2021 09:49:39 -0500 Received: from mx2.suse.de ([195.135.220.15]:34110 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727073AbhAKOti (ORCPT ); Mon, 11 Jan 2021 09:49:38 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 8074BAC95; Mon, 11 Jan 2021 14:48:57 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 46A7E1E0807; Mon, 11 Jan 2021 15:48:57 +0100 (CET) Date: Mon, 11 Jan 2021 15:48:57 +0100 From: Jan Kara To: Eric Biggers Cc: linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, Theodore Ts'o , Christoph Hellwig Subject: Re: [PATCH v2 02/12] fs: correctly document the inode dirty flags Message-ID: <20210111144857.GA18475@quack2.suse.cz> References: <20210109075903.208222-1-ebiggers@kernel.org> <20210109075903.208222-3-ebiggers@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210109075903.208222-3-ebiggers@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Fri 08-01-21 23:58:53, Eric Biggers wrote: > From: Eric Biggers > > The documentation for I_DIRTY_SYNC and I_DIRTY_DATASYNC is a bit > misleading, and I_DIRTY_TIME isn't documented at all. Fix this. > > Reviewed-by: Christoph Hellwig > Signed-off-by: Eric Biggers Looks good to me. You can add: Reviewed-by: Jan Kara Honza > --- > include/linux/fs.h | 18 +++++++++++++----- > 1 file changed, 13 insertions(+), 5 deletions(-) > > diff --git a/include/linux/fs.h b/include/linux/fs.h > index fd47deea7c176..45a0303b2aeb6 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -2084,8 +2084,8 @@ static inline void kiocb_clone(struct kiocb *kiocb, struct kiocb *kiocb_src, > /* > * Inode state bits. Protected by inode->i_lock > * > - * Three bits determine the dirty state of the inode, I_DIRTY_SYNC, > - * I_DIRTY_DATASYNC and I_DIRTY_PAGES. > + * Four bits determine the dirty state of the inode: I_DIRTY_SYNC, > + * I_DIRTY_DATASYNC, I_DIRTY_PAGES, and I_DIRTY_TIME. > * > * Four bits define the lifetime of an inode. Initially, inodes are I_NEW, > * until that flag is cleared. I_WILL_FREE, I_FREEING and I_CLEAR are set at > @@ -2094,12 +2094,20 @@ static inline void kiocb_clone(struct kiocb *kiocb, struct kiocb *kiocb_src, > * Two bits are used for locking and completion notification, I_NEW and I_SYNC. > * > * I_DIRTY_SYNC Inode is dirty, but doesn't have to be written on > - * fdatasync(). i_atime is the usual cause. > - * I_DIRTY_DATASYNC Data-related inode changes pending. We keep track of > + * fdatasync() (unless I_DIRTY_DATASYNC is also set). > + * Timestamp updates are the usual cause. > + * I_DIRTY_DATASYNC Data-related inode changes pending. We keep track of > * these changes separately from I_DIRTY_SYNC so that we > * don't have to write inode on fdatasync() when only > - * mtime has changed in it. > + * e.g. the timestamps have changed. > * I_DIRTY_PAGES Inode has dirty pages. Inode itself may be clean. > + * I_DIRTY_TIME The inode itself only has dirty timestamps, and the > + * lazytime mount option is enabled. We keep track of this > + * separately from I_DIRTY_SYNC in order to implement > + * lazytime. This gets cleared if I_DIRTY_INODE > + * (I_DIRTY_SYNC and/or I_DIRTY_DATASYNC) gets set. I.e. > + * either I_DIRTY_TIME *or* I_DIRTY_INODE can be set in > + * i_state, but not both. I_DIRTY_PAGES may still be set. > * I_NEW Serves as both a mutex and completion notification. > * New inodes set I_NEW. If two processes both create > * the same inode, one of them will release its inode and > -- > 2.30.0 > -- Jan Kara SUSE Labs, CR