linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zhang Yi <yi.zhang@huaweicloud.com>
To: Jan Kara <jack@suse.cz>
Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, tytso@mit.edu,
	adilger.kernel@dilger.ca, ritesh.list@gmail.com,
	yi.zhang@huawei.com, chengzhihao1@huawei.com, yukuai3@huawei.com
Subject: Re: [PATCH v2 10/10] ext4: factor out a common helper to lock and flush data before fallocate
Date: Tue, 24 Sep 2024 16:11:08 +0800	[thread overview]
Message-ID: <e6cceeee-9ff1-4638-8521-19ab40593693@huaweicloud.com> (raw)
In-Reply-To: <20240923085402.amto7pryy67eadpj@quack3>

On 2024/9/23 16:54, Jan Kara wrote:
> On Wed 04-09-24 14:29:25, Zhang Yi wrote:
>> From: Zhang Yi <yi.zhang@huawei.com>
>>
>> Now the beginning of the first four functions in ext4_fallocate() (punch
>> hole, zero range, insert range and collapse range) are almost the same,
>> they need to wait for the dio to finish, get filemap invalidate lock,
>> write back dirty data and finally drop page cache. Factor out a common
>> helper to do these work can reduce a lot of the redundant code.
>>
>> Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
> 
> I like that we factor out this functionality in a common helper. But see
> below:
> 
>> @@ -4731,6 +4707,52 @@ static int ext4_fallocate_check(struct inode *inode, int mode,
>>  	return 0;
>>  }
>>  
>> +int ext4_prepare_falloc(struct file *file, loff_t start, loff_t end, int mode)
>> +{
>> +	struct inode *inode = file_inode(file);
>> +	struct address_space *mapping = inode->i_mapping;
>> +	int ret;
>> +
>> +	/* Wait all existing dio workers, newcomers will block on i_rwsem */
>> +	inode_dio_wait(inode);
>> +	ret = file_modified(file);
>> +	if (ret)
>> +		return ret;
>> +
>> +	/*
>> +	 * Prevent page faults from reinstantiating pages we have released
>> +	 * from page cache.
>> +	 */
>> +	filemap_invalidate_lock(mapping);
>> +
>> +	ret = ext4_break_layouts(inode);
>> +	if (ret)
>> +		goto failed;
>> +
>> +	/*
>> +	 * Write data that will be zeroed to preserve them when successfully
>> +	 * discarding page cache below but fail to convert extents.
>> +	 */
>> +	ret = filemap_write_and_wait_range(mapping, start, end);
> 
> The comment is somewhat outdated now.

Sure, will update it in next iteration.

> Also the range is wrong for collapse
> and insert range. There we need to writeout data upto the EOF because we
> truncate it below.
> 

For collapse and insert range, I passed the length LLONG_MAX, which is
the same as before, this should've upto the EOF, so I think it's
right, or am I missing something?

ext4_collapse_range():

-	start = round_down(offset, PAGE_SIZE);
-	/* Write out all dirty pages */
-	ret = filemap_write_and_wait_range(mapping, start, LLONG_MAX);
+	ret = ext4_prepare_falloc(file, round_down(offset, PAGE_SIZE),
+				  LLONG_MAX, FALLOC_FL_COLLAPSE_RANGE);


ext4_insert_range():

-	start = round_down(offset, PAGE_SIZE);
-	/* Write out all dirty pages */
-	ret = filemap_write_and_wait_range(mapping, start, LLONG_MAX);
+	ret = ext4_prepare_falloc(file, round_down(offset, PAGE_SIZE),
+				  LLONG_MAX, FALLOC_FL_INSERT_RANGE);

Thanks,
Yi.

> 
>> +	if (ret)
>> +		goto failed;
>> +
>> +	/*
>> +	 * For insert range and collapse range, COWed private pages should
>> +	 * be removed since the file's logical offset will be changed, but
>> +	 * punch hole and zero range doesn't.
>> +	 */
>> +	if (mode & (FALLOC_FL_INSERT_RANGE | FALLOC_FL_COLLAPSE_RANGE))
>> +		truncate_pagecache(inode, start);
>> +	else
>> +		truncate_pagecache_range(inode, start, end);
>> +
>> +	return 0;
>> +failed:
>> +	filemap_invalidate_unlock(mapping);
>> +	return ret;
>> +}
> 


  reply	other threads:[~2024-09-24  8:11 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-04  6:29 [PATCH v2 00/10] ext4: clean up and refactor fallocate Zhang Yi
2024-09-04  6:29 ` [PATCH v2 01/10] ext4: write out dirty data before dropping pages Zhang Yi
2024-09-17 16:50   ` Jan Kara
2024-09-18 12:27     ` Zhang Yi
2024-09-04  6:29 ` [PATCH v2 02/10] ext4: don't explicit update times in ext4_fallocate() Zhang Yi
2024-09-20 16:04   ` Jan Kara
2024-09-04  6:29 ` [PATCH v2 03/10] ext4: drop ext4_update_disksize_before_punch() Zhang Yi
2024-09-20 16:13   ` Jan Kara
2024-09-24  7:43     ` Zhang Yi
2024-09-24 10:11       ` Jan Kara
2024-09-24 11:09         ` Zhang Yi
2024-09-04  6:29 ` [PATCH v2 04/10] ext4: refactor ext4_zero_range() Zhang Yi
2024-09-20 16:24   ` Jan Kara
2024-09-04  6:29 ` [PATCH v2 05/10] ext4: refactor ext4_punch_hole() Zhang Yi
2024-09-20 16:31   ` Jan Kara
2024-09-04  6:29 ` [PATCH v2 06/10] ext4: refactor ext4_collapse_range() Zhang Yi
2024-09-20 16:35   ` Jan Kara
2024-09-04  6:29 ` [PATCH v2 07/10] ext4: refactor ext4_insert_range() Zhang Yi
2024-09-23  8:17   ` Jan Kara
2024-09-04  6:29 ` [PATCH v2 08/10] ext4: factor out ext4_do_fallocate() Zhang Yi
2024-09-23  8:20   ` Jan Kara
2024-09-04  6:29 ` [PATCH v2 09/10] ext4: factor out the common checking part of all fallocate operations Zhang Yi
2024-09-23  8:31   ` Jan Kara
2024-09-24  7:52     ` Zhang Yi
2024-09-04  6:29 ` [PATCH v2 10/10] ext4: factor out a common helper to lock and flush data before fallocate Zhang Yi
2024-09-23  8:54   ` Jan Kara
2024-09-24  8:11     ` Zhang Yi [this message]
2024-09-24 10:05       ` Jan Kara

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=e6cceeee-9ff1-4638-8521-19ab40593693@huaweicloud.com \
    --to=yi.zhang@huaweicloud.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=chengzhihao1@huawei.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ritesh.list@gmail.com \
    --cc=tytso@mit.edu \
    --cc=yi.zhang@huawei.com \
    --cc=yukuai3@huawei.com \
    /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).