From: Allison Henderson <achender@linux.vnet.ibm.com>
To: Yongqiang Yang <xiaoqiangnk@gmail.com>
Cc: tytso@mit.edu, linux-ext4@vger.kernel.org
Subject: Re: [PATCH 4/6] ext4: remove code related to punching hole from ext4_ext_insert_extent
Date: Thu, 01 Dec 2011 13:55:37 -0700 [thread overview]
Message-ID: <4ED7E9C9.2020307@linux.vnet.ibm.com> (raw)
In-Reply-To: <1321495405-9583-4-git-send-email-xiaoqiangnk@gmail.com>
On 11/16/2011 07:03 PM, Yongqiang Yang wrote:
> Punch hole should never call ext4_ext_insert_extent, so this patch
> removes code related to it from ext4_ext_insert_extent.
>
> Signed-off-by: Yongqiang Yang<xiaoqiangnk@gmail.com>
> ---
> fs/ext4/extents.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
> index 6888d1a..720070d 100644
> --- a/fs/ext4/extents.c
> +++ b/fs/ext4/extents.c
> @@ -1737,8 +1737,6 @@ int ext4_ext_insert_extent(handle_t *handle, struct inode *inode,
> * There is no free space in the found leaf.
> * We're gonna add a new leaf in the tree.
> */
> - if (flag& EXT4_GET_BLOCKS_PUNCH_OUT_EXT)
> - flags = EXT4_MB_USE_ROOT_BLOCKS;
> err = ext4_ext_create_new_leaf(handle, inode, flags, path, newext);
> if (err)
> goto cleanup;
Hi Yongqiang,
Actually I believe it does end up inserting an extent if an extent gets
split. For example, we punch a hole in the middle of an extent, so we
first split the extent into three pieces, and remove the middle piece.
Because inserting the extra extents can require extra blocks, the
operation may temporarily consume blocks. The problem that this causes
is that if the file system is really full, it can fail with ENOSPC, even
though punch hole is an operation that is supposed to free blocks. The
above EXT4_MB_USE_ROOT_BLOCKS flag was put in so that when we punch
holes, we can borrow reserved blocks to complete the operation to avoid
the ENOSPC problem. I had a script to catch this and added to xfstests
(test 256). So unless there was a change somewhere that I missed, it
does not make sense to me to take it out at this point.
Allison Henderson
next prev parent reply other threads:[~2011-12-01 20:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-17 2:03 [PATCH 1/6] ext4: remove unnecessary var in ext4_ext_insert_extent Yongqiang Yang
2011-11-17 2:03 ` [PATCH 2/6] ext4: remove useless BUG_ON " Yongqiang Yang
2011-11-17 2:03 ` [PATCH 3/6] ext4: correct comment on extent merging " Yongqiang Yang
2011-11-17 2:03 ` [PATCH 4/6] ext4: remove code related to punching hole from ext4_ext_insert_extent Yongqiang Yang
2011-11-17 16:56 ` Andreas Dilger
2011-11-18 3:19 ` Yongqiang Yang
2011-12-01 20:55 ` Allison Henderson [this message]
2011-12-02 1:09 ` Yongqiang Yang
2011-11-17 2:03 ` [PATCH 5/6] ext4: remove useless code in ext4_ext_split Yongqiang Yang
2011-11-17 2:03 ` [PATCH 6/6] ext4: move code checking if leaf is full to the beginning of ext4_ext_split Yongqiang Yang
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=4ED7E9C9.2020307@linux.vnet.ibm.com \
--to=achender@linux.vnet.ibm.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=xiaoqiangnk@gmail.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).