linux-f2fs-devel.lists.sourceforge.net archive mirror
 help / color / mirror / Atom feed
From: "Sunmin Jeong" <s_min.jeong@samsung.com>
To: "'Chao Yu'" <chao@kernel.org>, <jaegeuk@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH 4/4] f2fs: atomic: fix to forbid dio in atomic_file
Date: Tue, 2 Jul 2024 21:13:09 +0900	[thread overview]
Message-ID: <5f6701dacc79$33afa870$9b0ef950$@samsung.com> (raw)
In-Reply-To: <20240625031351.3586955-4-chao@kernel.org>

Hello

I also have been thinking about the GC of the atomic file these days. I
read your patches for atomic write, but I think there are some corner
cases that can't be resolved with them.

First is when the GC of the atomic file occurs right after the writeback
of newly updated page. Since the atomic page flag is cleared at the end
of f2fs_do_write_data_page, the GC thread will set the page dirty and
let it be written to the atomic file, which will cause the data
corruption of the original inode.

Second is the foreground GC of atomic file. Although your patch can
distinguish whether pages should be written to the original inode or cow
inode, it can't handle the case when the atomic page needs to be
migrated but updated page already exists in the page cache as below.

// atomic file's 1st old block is a and new block is b.
// b is in the page cache
GC thread(FG_GC)
  - select A as a victim segment
  do_garbage_collect
    - iget atomic file's inode for block a
    move_data_page
      f2fs_do_write_data_page
        - use dn of cow inode since b has atomic flag
    - seg_freed is 0 since block a is still valid
    - goto gc_more and A is selected as victim again

Third is a race condition between GC of cow file and writeback thread of
atomic file. Since there are two page caches for one dnode, I think we
need to consider the race condition between them such as the case
between the file inode and the meta inode.

I submitted a patch set for atomic write, so could you review it?
The patch links are as below.
https://sourceforge.net/p/linux-f2fs/mailman/message/58790988/
https://sourceforge.net/p/linux-f2fs/mailman/message/58790989/

Thanks



> atomic write can only be used via buffered IO, let's fail direct IO on
> atomic_file and return -EOPNOTSUPP.
> 
> Signed-off-by: Chao Yu <chao@kernel.org>
> ---
>  fs/f2fs/file.c | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index
> 0355cb054521..a527de1e7a2f 100644
> --- a/fs/f2fs/file.c
> +++ b/fs/f2fs/file.c
> @@ -2150,6 +2150,7 @@ static int f2fs_ioc_start_atomic_write(struct file
> *filp, bool truncate)
>  		goto out;
> 
>  	f2fs_down_write(&fi->i_gc_rwsem[WRITE]);
> +	f2fs_down_write(&fi->i_gc_rwsem[READ]);
> 
>  	/*
>  	 * Should wait end_io to count F2FS_WB_CP_DATA correctly by @@ -
> 2209,6 +2210,7 @@ static int f2fs_ioc_start_atomic_write(struct file
*filp,
> bool truncate)
>  	}
>  	f2fs_i_size_write(fi->cow_inode, isize);
> 
> +	f2fs_up_write(&fi->i_gc_rwsem[READ]);
>  	f2fs_up_write(&fi->i_gc_rwsem[WRITE]);
> 
>  	f2fs_update_time(sbi, REQ_TIME);
> @@ -4537,6 +4539,13 @@ static ssize_t f2fs_dio_read_iter(struct kiocb
> *iocb, struct iov_iter *to)
>  		f2fs_down_read(&fi->i_gc_rwsem[READ]);
>  	}
> 
> +	/* dio is not compatible w/ atomic file */
> +	if (f2fs_is_atomic_file(inode)) {
> +		f2fs_up_read(&fi->i_gc_rwsem[READ]);
> +		ret = -EOPNOTSUPP;
> +		goto out;
> +	}
> +
>  	/*
>  	 * We have to use __iomap_dio_rw() and iomap_dio_complete() instead
> of
>  	 * the higher-level function iomap_dio_rw() in order to ensure that
> the @@ -4948,6 +4957,12 @@ static ssize_t f2fs_file_write_iter(struct
> kiocb *iocb, struct iov_iter *from)
>  	/* Determine whether we will do a direct write or a buffered write.
> */
>  	dio = f2fs_should_use_dio(inode, iocb, from);
> 
> +	/* dio is not compatible w/ atomic write */
> +	if (dio && f2fs_is_atomic_file(inode)) {
> +		ret = -EOPNOTSUPP;
> +		goto out_unlock;
> +	}
> +
>  	/* Possibly preallocate the blocks for the write. */
>  	target_size = iocb->ki_pos + iov_iter_count(from);
>  	preallocated = f2fs_preallocate_blocks(iocb, from, dio);
> --
> 2.40.1
> 
> 
> 
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  reply	other threads:[~2024-07-02 12:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-25  3:13 [f2fs-dev] [PATCH 1/4] f2fs: atomic: fix to avoid racing w/ GC Chao Yu
2024-06-25  3:13 ` [f2fs-dev] [PATCH 2/4] f2fs: atomic: fix to not allow GC to pollute atomic_file Chao Yu
2024-06-25  3:13 ` [f2fs-dev] [PATCH 3/4] f2fs: atomic: fix to truncate pagecache before on-disk metadata truncation Chao Yu
2024-07-25 20:54   ` Jaegeuk Kim
2024-07-26  1:06     ` Chao Yu
2024-06-25  3:13 ` [f2fs-dev] [PATCH 4/4] f2fs: atomic: fix to forbid dio in atomic_file Chao Yu
2024-07-02 12:13   ` Sunmin Jeong [this message]
2024-08-05 23:30 ` [f2fs-dev] [PATCH 1/4] f2fs: atomic: fix to avoid racing w/ GC patchwork-bot+f2fs

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='5f6701dacc79$33afa870$9b0ef950$@samsung.com' \
    --to=s_min.jeong@samsung.com \
    --cc=chao@kernel.org \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).