[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210111150603.GI18475@quack2.suse.cz>
Date: Mon, 11 Jan 2021 16:06:03 +0100
From: Jan Kara <jack@...e.cz>
To: Eric Biggers <ebiggers@...nel.org>
Cc: linux-fsdevel@...r.kernel.org, linux-xfs@...r.kernel.org,
linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net,
Theodore Ts'o <tytso@....edu>, Christoph Hellwig <hch@....de>
Subject: Re: [PATCH v2 10/12] gfs2: don't worry about I_DIRTY_TIME in
gfs2_fsync()
On Fri 08-01-21 23:59:01, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@...gle.com>
>
> The I_DIRTY_TIME flag is primary used within the VFS, and there's no
> reason for ->fsync() implementations to do anything with it. This is
> because when !datasync, the VFS will expire dirty timestamps before
> calling ->fsync(). (See vfs_fsync_range().) This turns I_DIRTY_TIME
> into I_DIRTY_SYNC.
>
> Therefore, change gfs2_fsync() to not check for I_DIRTY_TIME.
>
> Reviewed-by: Christoph Hellwig <hch@....de>
> Signed-off-by: Eric Biggers <ebiggers@...gle.com>
Looks good to me. Feel free to add:
Reviewed-by: Jan Kara <jack@...e.cz>
Honza
> ---
> fs/gfs2/file.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/gfs2/file.c b/fs/gfs2/file.c
> index b39b339feddc9..7fe2497755a37 100644
> --- a/fs/gfs2/file.c
> +++ b/fs/gfs2/file.c
> @@ -749,7 +749,7 @@ static int gfs2_fsync(struct file *file, loff_t start, loff_t end,
> {
> struct address_space *mapping = file->f_mapping;
> struct inode *inode = mapping->host;
> - int sync_state = inode->i_state & I_DIRTY_ALL;
> + int sync_state = inode->i_state & I_DIRTY;
> struct gfs2_inode *ip = GFS2_I(inode);
> int ret = 0, ret1 = 0;
>
> @@ -762,7 +762,7 @@ static int gfs2_fsync(struct file *file, loff_t start, loff_t end,
> if (!gfs2_is_jdata(ip))
> sync_state &= ~I_DIRTY_PAGES;
> if (datasync)
> - sync_state &= ~(I_DIRTY_SYNC | I_DIRTY_TIME);
> + sync_state &= ~I_DIRTY_SYNC;
>
> if (sync_state) {
> ret = sync_inode_metadata(inode, 1);
> --
> 2.30.0
>
--
Jan Kara <jack@...e.com>
SUSE Labs, CR
Powered by blists - more mailing lists