public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Ben Myers <bpm@sgi.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 0/2] xfs: defrag support for v5 filesystems
Date: Tue, 3 Sep 2013 14:12:01 -0500	[thread overview]
Message-ID: <20130903191201.GL1935@sgi.com> (raw)
In-Reply-To: <1377822225-17621-1-git-send-email-david@fromorbit.com>

Hey Dave,

On Fri, Aug 30, 2013 at 10:23:43AM +1000, Dave Chinner wrote:
> Hi folks,
> 
> The following 2 patches implement the BMBT owner change transaction
> that is necessary to enable the XFS_IOC_SWAPEXT ioctl to operate on
> v5 filesystems correctly. The first patch implements the
> transactional runtime change, and the second patch implements the
> recovery of that change.
> 
> Both the run time and recovery code use the same mechanism for
> changing the owner field in all the blocks in the BMBT on an inode,
> and even though XFS_IOC_SWAPEXT only swaps the data fork, the code
> has been written to be fork neutral so if we even need to swap
> attribute forks it should just work for that, too.
> 
> Further, because the BMBT code uses the generic btree
> infrastructure, the btree modification is done as a generic function
> as well and so should work for all types of btrees supported by the
> generic code. Hence if the need arises we can easily change the
> owner of any btree that uses the generic code.
> 
> The testing carried out is documented in the description of the
> second patch.
> 
> AFAIA, this is the only remaining feature that the kernel v5
> filesystem implementation didn't support. Hence, with this patchset,
> there are no more feature checkboxes that need to be ticked that
> would prevent us from removing the experimental tag from it. Testing
> is the only remaining gate to removing the tag from the kernel
> code...

I believe there is still the discussion surrounding being able to use
the self describing metadata without enabling crcs that needs to be
resolved before removing the experimental tag.  Some customers will want
to use features such as t10-dif and won't want to calculate two separate
crcs.  Normally that discussion probably needn't gate the removal of the
experimental tag, but unfortunately there will be some compatability
issues surrounding an additional feature bit and modification of mkfs
that we should probably iron out first.

Other than that discussion, I think we're about on the same page...

Regards,
	Ben

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

  parent reply	other threads:[~2013-09-03 19:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-30  0:23 [PATCH 0/2] xfs: defrag support for v5 filesystems Dave Chinner
2013-08-30  0:23 ` [PATCH 1/2] xfs: swap extents operations for CRC filesystems Dave Chinner
2013-09-09 20:32   ` Mark Tinguely
2013-08-30  0:23 ` [PATCH 2/2] xfs: recovery of " Dave Chinner
2013-09-09 20:37   ` Mark Tinguely
2013-09-03 19:12 ` Ben Myers [this message]
2013-09-03 22:45   ` [PATCH 0/2] xfs: defrag support for v5 filesystems Dave Chinner
2013-09-05 19:34     ` Ben Myers
2013-09-05 19:57       ` Eric Sandeen
2013-09-05 20:03         ` Eric Sandeen
2013-09-06  3:34         ` Dave Chinner
2013-09-10 17:51 ` 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=20130903191201.GL1935@sgi.com \
    --to=bpm@sgi.com \
    --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