xfs
[Top] [All Lists]

Re: [PATCH v3 07/18] xfs: handle sparse inode chunks in icreate log reco

To: Brian Foster <bfoster@xxxxxxxxxx>
Subject: Re: [PATCH v3 07/18] xfs: handle sparse inode chunks in icreate log recovery
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Sat, 7 Feb 2015 10:19:46 +1100
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <1423252385-3063-8-git-send-email-bfoster@xxxxxxxxxx>
References: <1423252385-3063-1-git-send-email-bfoster@xxxxxxxxxx> <1423252385-3063-8-git-send-email-bfoster@xxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Fri, Feb 06, 2015 at 02:52:54PM -0500, Brian Foster wrote:
> Recovery of icreate transactions assumes hardcoded values for the inode
> count and chunk length.
> 
> Sparse inode chunks are allocated in units of m_ialloc_min_blks. Update
> the icreate validity checks to allow for appropriately sized inode
> chunks and verify the inode count matches what is expected based on the
> extent length rather than assuming a hardcoded count.
> 
> Signed-off-by: Brian Foster <bfoster@xxxxxxxxxx>
> ---
>  fs/xfs/xfs_log_recover.c | 19 +++++++++++++------
>  1 file changed, 13 insertions(+), 6 deletions(-)
> 
> diff --git a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c
> index ecc73d5..5a5ee20 100644
> --- a/fs/xfs/xfs_log_recover.c
> +++ b/fs/xfs/xfs_log_recover.c
> @@ -3068,12 +3068,19 @@ xlog_recover_do_icreate_pass2(
>               return -EINVAL;
>       }
>  
> -     /* existing allocation is fixed value */
> -     ASSERT(count == mp->m_ialloc_inos);
> -     ASSERT(length == mp->m_ialloc_blks);
> -     if (count != mp->m_ialloc_inos ||
> -          length != mp->m_ialloc_blks) {
> -             xfs_warn(log->l_mp, "xlog_recover_do_icreate_trans: bad count 
> 2");
> +     /* inode chunk is either full or sparse */
> +     if (length != mp->m_ialloc_blks &&
> +         length != mp->m_ialloc_min_blks) {
> +             xfs_warn(log->l_mp,
> +                      "%s: unsupported chunk length", __FUNCTION__);
> +             return -EINVAL;
> +     }

Hmmm - this would prevent recovery of sparse inode chunk allocation
in multiples of mp->m_ialloc_min_blks, right? Surely we can allow
any sub-chunk extent size to be allocated as long as alignment and
size restrictions are met?

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>