All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Eric Sandeen <sandeen@redhat.com>
Cc: Gabriel VLASIU <gabriel@vlasiu.net>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH] xfs: check on-disk (not incore) btree root size in dfrag.c
Date: Wed, 28 Mar 2012 08:16:51 +1100	[thread overview]
Message-ID: <20120327211651.GD5091@dastard> (raw)
In-Reply-To: <4F722828.4000102@redhat.com>

On Tue, Mar 27, 2012 at 03:50:48PM -0500, Eric Sandeen wrote:
> On 3/27/12 3:40 PM, Eric Sandeen wrote:
> > xfs_swap_extents_check_format() contains checks to make sure that
> > original and the temporary files during defrag are compatible;
> > Gabriel VLASIU ran into a case where xfs_fsr returned EINVAL
> > because the tests found the btree root to be of size 120,
> > while the fork offset was only 104; IOW, they overlapped.
> > 
> > However, this is just due to an error in the
> > xfs_swap_extents_check_format() tests, because it is checking
> > the in-memory btree root size against the on-disk fork offset.
> > We should be checking the on-disk sizes in both cases.
> > 
> > This patch adds a new macro to calculate this size, and uses
> > it in the tests.
> > 
> > With this change, the filesystem image provided by Gabriel
> > allows for proper file degragmentation.
> 
> Hm, as usually happens right after finalizing this I stumbled
> on something else.  xfs_iroot_realloc() does essentially the same
> test, but uses a funky macro to resolve the incore/ondisk size
> difference:
> 
>         ASSERT(ifp->if_broot_bytes <=
>                 XFS_IFORK_SIZE(ip, whichfork) + XFS_BROOT_SIZE_ADJ);
> 
> so dfrag.c could be fixed up the same way, I suppose, using
> XFS_BROOT_SIZE_ADJ if desired (though I have no real love for that
> undocumented macro!)

I much prefer the addition of a XFS_BMAP_BMDR_SPACE() macro. Perhaps
it might be worthwhile to convert those uses of XFS_BROOT_SIZE_ADJ
to use your new macro, and get rid of the XFS_BROOT_SIZE_ADJ grot
altogether?

Anyway, consider your patch:

Reviewed-by: Dave Chinner <dchinner@redhat.com>

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2012-03-27 21:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-27 20:40 [PATCH] xfs: check on-disk (not incore) btree root size in dfrag.c Eric Sandeen
2012-03-27 20:50 ` Eric Sandeen
2012-03-27 21:16   ` Dave Chinner [this message]
2012-03-28 17:21 ` [PATCH 2/1] xfs: use XFS_BMAP_BMDR_SPACE vs. XFS_BROOT_SIZE_ADJ Eric Sandeen
2012-03-29  0:55   ` Dave Chinner
2013-06-19 21:51 ` [PATCH] xfs: check on-disk (not incore) btree root size in dfrag.c Eric Sandeen
2013-06-20 17:09   ` Ben Myers
2013-07-09 16:26     ` Eric Sandeen
2013-07-09 18:22       ` Ben Myers

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=20120327211651.GD5091@dastard \
    --to=david@fromorbit.com \
    --cc=gabriel@vlasiu.net \
    --cc=sandeen@redhat.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.