From: Brian Foster <bfoster@redhat.com>
To: Namjae Jeon <namjae.jeon@samsung.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] xfs: remove XFS_TRANS_RESERVE in collapse range
Date: Thu, 8 May 2014 09:36:37 -0400 [thread overview]
Message-ID: <20140508133637.GB47272@bfoster.bfoster> (raw)
In-Reply-To: <002601cf6aa2$c59cd670$50d68350$@samsung.com>
On Thu, May 08, 2014 at 06:49:14PM +0900, Namjae Jeon wrote:
> There is no need to dip into reserve pool. Reserve pool is used for much
> more important things. And xfs_trans_reserve will never return ENOSPC
> because punch hole is already done. If we get ENOSPC, collapse range
> will be simply failed.
>
> Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
> Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com>
> ---
> fs/xfs/xfs_bmap_util.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c
> index 296160b..91a43c5 100644
> --- a/fs/xfs/xfs_bmap_util.c
> +++ b/fs/xfs/xfs_bmap_util.c
> @@ -1519,7 +1519,6 @@ xfs_collapse_file_space(
>
> while (!error && !done) {
> tp = xfs_trans_alloc(mp, XFS_TRANS_DIOSTRAT);
> - tp->t_flags |= XFS_TRANS_RESERVE;
Makes sense.
> /*
> * We would need to reserve permanent block for transaction.
> * This will come into picture when after shifting extent into
> @@ -1529,7 +1528,7 @@ xfs_collapse_file_space(
> error = xfs_trans_reserve(tp, &M_RES(mp)->tr_write,
> XFS_DIOSTRAT_SPACE_RES(mp, 0), 0);
> if (error) {
> - ASSERT(error == ENOSPC || XFS_FORCED_SHUTDOWN(mp));
> + ASSERT(XFS_FORCED_SHUTDOWN(mp));
The xfs_trans_reserve() call still reserves XFS_DIOSTRAT_SPACE_RES()
blocks, so therefore I think ENOSPC is still a possibility. The question
is probably whether or not we need to reserve blocks for this
transaction.
Making a pass through the code... we have the possibility of deleting a
btree record in xfs_bmap_shift_extents(). This in turn could potentially
free a btree block, which frees space. I _think_ this could mean we
want to keep the block reservation because we update the free space
trees, but I suppose that could be handled by the freelist...
Perhaps Dave can confirm which direction we should go here..?
Brian
> xfs_trans_cancel(tp, 0);
> break;
> }
> --
> 1.7.11-rc0
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-05-08 13:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-08 9:49 [PATCH] xfs: remove XFS_TRANS_RESERVE in collapse range Namjae Jeon
2014-05-08 13:36 ` Brian Foster [this message]
2014-05-08 21:17 ` Dave Chinner
2014-05-08 21:51 ` Brian Foster
2014-05-08 22:05 ` Dave Chinner
2014-05-12 23:53 ` Namjae Jeon
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=20140508133637.GB47272@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=namjae.jeon@samsung.com \
--cc=xfs@oss.sgi.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