2013-04-27 04:31:40

by Ashish Sangwan

[permalink] [raw]
Subject: [PATCH] ext4: remove unneeded call to ext4_es_remove_extent in punch hole

From: Ashish Sangwan <[email protected]>

During punch hole, before removing extents we make sure that the blocks
are commited to disk by calling filemap_write_and_wait_range. So, the
extents cannot be present on extent status tree.

Signed-off-by: Ashish Sangwan <[email protected]>
Signed-off-by: Namjae Jeon <[email protected]>
---
fs/ext4/inode.c | 7 -------
1 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 50cced9..944eb15 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -3749,13 +3749,6 @@ int ext4_punch_hole(struct file *file, loff_t offset, loff_t length)
down_write(&EXT4_I(inode)->i_data_sem);
ext4_discard_preallocations(inode);

- ret = ext4_es_remove_extent(inode, first_block,
- stop_block - first_block);
- if (ret) {
- up_write(&EXT4_I(inode)->i_data_sem);
- goto out_stop;
- }


2013-04-27 05:10:45

by Zheng Liu

[permalink] [raw]
Subject: Re: [PATCH] ext4: remove unneeded call to ext4_es_remove_extent in punch hole

On Sat, Apr 27, 2013 at 10:00:53AM +0530, Ashish Sangwan wrote:
> From: Ashish Sangwan <[email protected]>
>
> During punch hole, before removing extents we make sure that the blocks
> are commited to disk by calling filemap_write_and_wait_range. So, the
> extents cannot be present on extent status tree.
>
> Signed-off-by: Ashish Sangwan <[email protected]>
> Signed-off-by: Namjae Jeon <[email protected]>

Hi Ashish,

I guess that this patch is against mainline kernel, right? The commit
log is right before we use extent status tree to track all extent
information. In dev branch of ext4 tree, we track all extent status in
status tree. So we need to remove extent from status tree in punch
hole.

Thanks,
- Zheng

> ---
> fs/ext4/inode.c | 7 -------
> 1 files changed, 0 insertions(+), 7 deletions(-)
>
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 50cced9..944eb15 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -3749,13 +3749,6 @@ int ext4_punch_hole(struct file *file, loff_t offset, loff_t length)
> down_write(&EXT4_I(inode)->i_data_sem);
> ext4_discard_preallocations(inode);
>
> - ret = ext4_es_remove_extent(inode, first_block,
> - stop_block - first_block);
> - if (ret) {
> - up_write(&EXT4_I(inode)->i_data_sem);
> - goto out_stop;
> - }
> -
> if (ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS))
> ret = ext4_ext_remove_space(inode, first_block,
> stop_block - 1);
> --
> 1.7.8.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html

2013-04-27 06:50:23

by Ashish Sangwan

[permalink] [raw]
Subject: Re: [PATCH] ext4: remove unneeded call to ext4_es_remove_extent in punch hole

On Sat, Apr 27, 2013 at 10:58 AM, Zheng Liu <[email protected]> wrote:
> On Sat, Apr 27, 2013 at 10:00:53AM +0530, Ashish Sangwan wrote:
>> From: Ashish Sangwan <[email protected]>
>>
>> During punch hole, before removing extents we make sure that the blocks
>> are commited to disk by calling filemap_write_and_wait_range. So, the
>> extents cannot be present on extent status tree.
>>
>> Signed-off-by: Ashish Sangwan <[email protected]>
>> Signed-off-by: Namjae Jeon <[email protected]>
>
> Hi Ashish,
>
> I guess that this patch is against mainline kernel, right?
True

>The commit
> log is right before we use extent status tree to track all extent
> information. In dev branch of ext4 tree, we track all extent status in
> status tree. So we need to remove extent from status tree in punch
> hole.
I was of the opinion that filemap_write_and_wait_range will remove the
extent from status tree if its still there.
ok, I will check the dev branch.

Thanks,
Ashish
>
> Thanks,
> - Zheng
>
>> ---
>> fs/ext4/inode.c | 7 -------
>> 1 files changed, 0 insertions(+), 7 deletions(-)
>>
>> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
>> index 50cced9..944eb15 100644
>> --- a/fs/ext4/inode.c
>> +++ b/fs/ext4/inode.c
>> @@ -3749,13 +3749,6 @@ int ext4_punch_hole(struct file *file, loff_t offset, loff_t length)
>> down_write(&EXT4_I(inode)->i_data_sem);
>> ext4_discard_preallocations(inode);
>>
>> - ret = ext4_es_remove_extent(inode, first_block,
>> - stop_block - first_block);
>> - if (ret) {
>> - up_write(&EXT4_I(inode)->i_data_sem);
>> - goto out_stop;
>> - }
>> -
>> if (ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS))
>> ret = ext4_ext_remove_space(inode, first_block,
>> stop_block - 1);
>> --
>> 1.7.8.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html

2013-04-27 06:53:44

by Zheng Liu

[permalink] [raw]
Subject: Re: [PATCH] ext4: remove unneeded call to ext4_es_remove_extent in punch hole

On Sat, Apr 27, 2013 at 12:20:22PM +0530, Ashish Sangwan wrote:
> >The commit
> > log is right before we use extent status tree to track all extent
> > information. In dev branch of ext4 tree, we track all extent status in
> > status tree. So we need to remove extent from status tree in punch
> > hole.
> I was of the opinion that filemap_write_and_wait_range will remove the
> extent from status tree if its still there.
> ok, I will check the dev branch.

Ah, please bear with me. In mainline kernel 3.9-rcX, we have used
status tree to track all extent status. You could also check 3.9-rcX
kernel. Please let me know if I miss something.

Thanks,
- Zheng

2013-04-29 08:40:43

by Ashish Sangwan

[permalink] [raw]
Subject: Re: [PATCH] ext4: remove unneeded call to ext4_es_remove_extent in punch hole

On Sat, Apr 27, 2013 at 12:41 PM, Zheng Liu <[email protected]> wrote:
> On Sat, Apr 27, 2013 at 12:20:22PM +0530, Ashish Sangwan wrote:
>> >The commit
>> > log is right before we use extent status tree to track all extent
>> > information. In dev branch of ext4 tree, we track all extent status in
>> > status tree. So we need to remove extent from status tree in punch
>> > hole.
>> I was of the opinion that filemap_write_and_wait_range will remove the
>> extent from status tree if its still there.
>> ok, I will check the dev branch.
>
> Ah, please bear with me. In mainline kernel 3.9-rcX, we have used
> status tree to track all extent status. You could also check 3.9-rcX
> kernel. Please let me know if I miss something.
Hi Zheng,

Ok, I understood your point.
Currently, after step 2 of extent status tree, it houses _all_ the
extents and not just delayed extents.
This patch is not required now.

Regards,
Ashish
>
> Thanks,
> - Zheng