From: Mark Goodwin <markgw@sgi.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com, kevin@kevinjamieson.com
Subject: Re: [PATCH] XFS: Account for allocated blocks when expanding directories
Date: Tue, 30 Sep 2008 11:46:08 +1000 [thread overview]
Message-ID: <48E184E0.4020301@sgi.com> (raw)
In-Reply-To: <1222737924-18884-1-git-send-email-david@fromorbit.com>
Hi Dave,
by the looks of it, this is a proposed fix for the bug reported
by Kevin Jamieson (and others in the past) :
"xfs_trans_cancel at line 1138 of file fs/xfs/xfs_trans.c"
Do you (or Kevin or anyone) have a reliable test case to reproduce
this?
Cheers
-- Mark
Dave Chinner wrote:
> When we create a directory, we reserve a number of blocks for
> the maximum possible expansion of of the directory due to
> various btree splits, freespace allocation, etc. Unfortunately,
> each allocation is not reflected in the total number of blocks
> still available to the transaction, so the maximal reservation
> is used over and over again.
>
> This leads to problems where an allocation group has only
> enough blocks for *some* of the allocations required for the
> directory modification. After the first N allocations, the
> remaining blocks in the allocation group drops below the total
> reservation, and subsequent allocations fail because the allocator
> will not allow the allocation to proceed if the AG does not have
> the enough blocks available for the entire allocation total.
>
> This results in an ENOSPC occurring after an allocation has
> already occurred. This results in aborting the directory
> operation (leaving the directory in an inconsistent state)
> and cancelling a dirty transaction, which results in a filesystem
> shutdown.
>
> Avoid the problem by reflecting the number of blocks allocated in
> any directory expansion in the total number of blocks available to
> the modification in progress. This prevents a directory modification
> from being aborted part way through with an ENOSPC.
>
> Signed-off-by: Dave Chinner <david@fromorbit.com>
> ---
> fs/xfs/xfs_da_btree.c | 5 +++++
> fs/xfs/xfs_dir2.c | 6 ++++++
> 2 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/fs/xfs/xfs_da_btree.c b/fs/xfs/xfs_da_btree.c
> index 9e561a9..a11a839 100644
> --- a/fs/xfs/xfs_da_btree.c
> +++ b/fs/xfs/xfs_da_btree.c
> @@ -1566,11 +1566,14 @@ xfs_da_grow_inode(xfs_da_args_t *args, xfs_dablk_t *new_blkno)
> int nmap, error, w, count, c, got, i, mapi;
> xfs_trans_t *tp;
> xfs_mount_t *mp;
> + xfs_drfsbno_t nblks;
>
> dp = args->dp;
> mp = dp->i_mount;
> w = args->whichfork;
> tp = args->trans;
> + nblks = dp->i_d.di_nblocks;
> +
> /*
> * For new directories adjust the file offset and block count.
> */
> @@ -1647,6 +1650,8 @@ xfs_da_grow_inode(xfs_da_args_t *args, xfs_dablk_t *new_blkno)
> }
> if (mapp != &map)
> kmem_free(mapp);
> + /* account for newly allocated blocks in reserved blocks total */
> + args->total -= dp->i_d.di_nblocks - nblks;
> *new_blkno = (xfs_dablk_t)bno;
> return 0;
> }
> diff --git a/fs/xfs/xfs_dir2.c b/fs/xfs/xfs_dir2.c
> index 80e0dc5..1afb122 100644
> --- a/fs/xfs/xfs_dir2.c
> +++ b/fs/xfs/xfs_dir2.c
> @@ -525,11 +525,13 @@ xfs_dir2_grow_inode(
> xfs_mount_t *mp;
> int nmap; /* number of bmap entries */
> xfs_trans_t *tp;
> + xfs_drfsbno_t nblks;
>
> xfs_dir2_trace_args_s("grow_inode", args, space);
> dp = args->dp;
> tp = args->trans;
> mp = dp->i_mount;
> + nblks = dp->i_d.di_nblocks;
> /*
> * Set lowest possible block in the space requested.
> */
> @@ -622,7 +624,11 @@ xfs_dir2_grow_inode(
> */
> if (mapp != &map)
> kmem_free(mapp);
> +
> + /* account for newly allocated blocks in reserved blocks total */
> + args->total -= dp->i_d.di_nblocks - nblks;
> *dbp = xfs_dir2_da_to_db(mp, (xfs_dablk_t)bno);
> +
> /*
> * Update file's size if this is the data space and it grew.
> */
--
Mark Goodwin markgw@sgi.com
Engineering Manager for XFS and PCP Phone: +61-3-99631937
SGI Australian Software Group Cell: +61-4-18969583
-------------------------------------------------------------
next prev parent reply other threads:[~2008-09-30 1:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-30 1:25 [PATCH] XFS: Account for allocated blocks when expanding directories Dave Chinner
2008-09-30 1:46 ` Mark Goodwin [this message]
2008-09-30 2:09 ` Dave Chinner
-- strict thread matches above, loose matches on Subject: below --
2008-10-07 21:58 Dave Chinner
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=48E184E0.4020301@sgi.com \
--to=markgw@sgi.com \
--cc=david@fromorbit.com \
--cc=kevin@kevinjamieson.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.