From: Christoph Hellwig <hch@infradead.org>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 1/3] xfs: xfs_swap_extents needs to handle dynamic fork offsets
Date: Thu, 14 Jan 2010 01:42:55 -0500 [thread overview]
Message-ID: <20100114064255.GB29458@infradead.org> (raw)
In-Reply-To: <1263432836-13368-2-git-send-email-david@fromorbit.com>
On Thu, Jan 14, 2010 at 12:33:54PM +1100, Dave Chinner wrote:
> When swapping extents, we can corrupt inodes by swapping data forks
> that are in incompatible formats. This is caused by the two indoes
> having different fork offsets due to the presence of an attribute
> fork on an attr2 filesystem. xfs_fsr tries to be smart about
> setting the fork offset, but the trick it plays only works on attr1
> (old fixed format attribute fork) filesystems.
>
> Changing the way xfs_fsr sets up the attribute fork will prevent
> this situation from ever occurring, so in the kernel code we can get
> by with a preventative fix - check that the data fork in the
> defragmented inode is in a format valid for the inode it is being
> swapped into. This will lead to files that will silently and
> potentially repeatedly fail defragmentation, so issue a warning to
> the log when this particular failure occurs to let us know that
> xfs_fsr needs updating/fixing.
>
> To help identify how to improve xfs_fsr to avoid this issue, add
> trace points for the inodes being swapped so that we can determine
> why the swap was rejected and to confirm that the code is making the
> right decisions and modifications when swapping forks.
>
> A further complication is even when the swap is allowed to proceed
> when the fork offset is different between the two inodes then value
> for the maximum number of extents the data fork can hold can be
> wrong. Make sure these are also set correctly after the swap occurs.
>
> Signed-off-by: Dave Chinner <david@fromorbit.com>
> ---
> fs/xfs/xfs_dfrag.c | 106 ++++++++++++++++++++++++++++++++++++++++++++--------
Looks good,
Reviewed-by: Christoph Hellwig <hch@lst.de>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2010-01-14 6:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-14 1:33 [PATCH 0/3] Split version of xfs_swap_extents bug fix Dave Chinner
2010-01-14 1:33 ` [PATCH 1/3] xfs: xfs_swap_extents needs to handle dynamic fork offsets Dave Chinner
2010-01-14 6:42 ` Christoph Hellwig [this message]
2010-01-14 1:33 ` [PATCH 2/3] xfs: add tracing to xfs_swap_extents Dave Chinner
2010-01-14 1:33 ` [PATCH 3/3] xfs: clean up inconsistent variable naming in xfs_swap_extent Dave Chinner
2010-01-14 15:41 ` [PATCH 3/3] xfs: clean up inconsistent variable naming inxfs_swap_extent Alex Elder
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=20100114064255.GB29458@infradead.org \
--to=hch@infradead.org \
--cc=david@fromorbit.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