public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Ben Myers <bpm@sgi.com>, Rich Johnston <rjohnston@sgi.com>,
	xfs-oss <xfs@oss.sgi.com>
Subject: Re: [ANNOUNCE] xfsprogs v3.2.0-alpha2
Date: Thu, 5 Dec 2013 10:32:39 +1100	[thread overview]
Message-ID: <20131204233239.GF8803@dastard> (raw)
In-Reply-To: <20131204110023.GA3263@infradead.org>

On Wed, Dec 04, 2013 at 03:00:23AM -0800, Christoph Hellwig wrote:
> On Tue, Dec 03, 2013 at 04:43:54PM -0600, Ben Myers wrote:
> > IIRC last time we discussed this I expressed a preference for focussing
> > on the 3.2.0 release, but did not object to a 3.1.12 either.  I think
> > Eric followed up and asked if Christoph had specific concerns that
> > should prompt a 3.1.12 release.  Now I think it's probably just best to
> > focus on the xfs_repair bits for 3.2.0.
> 
> My concern is pretty simple: we have a big batch of minor and not so
> minor fixes that I want to get out to our users.  We've done releases
> about every 3 month for the last couple years, but we've not done any
> for 6 month by now.
> 
> I have to admit I'm a bit out of the loop on the v5 repair work, but if
> Dave feels confident that he can get it done soon we should aim for a
> 3.2.0 release after that.  If not it's more than time to get a 3.1.12
> out and I'd be happy to do the work for it.

There's a bit of mess involved in the repair stuff - basically
propagating CRC errors and other errors detected by the verifiers
is a bit nasty and touches a lot of the repair code (think
everywhere that reads a buffer). I'm trying to work out a sane way
to handle this, but I haven't managed to do it in a manner I
consider acceptable and maintainable in the long term yet. Once I
work out a method of doing that sanely, I'll mangle the code to
handle it.

However, this really needs changes to the verifier instructure to be
able to distinguish between CRC errors and structure corruption
errors, so there's kernel changes that need to be done there as
well. Eventually we need the same distinction in the kernel code,
so I need to work it all out in terms of what reapir needs, then do
the kernel mods, and then port them back to userspace....

In short, there's still a significant amount of work needed here.

Oh, and there's still the dir ftype validation that needs to be
done - that's a separate piece of work, so maybe someone else
would like to tackle that so it gets done sooner?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

      parent reply	other threads:[~2013-12-04 23:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-25 19:35 [ANNOUNCE] xfsprogs v3.2.0-alpha2 Rich Johnston
2013-11-28 10:40 ` Christoph Hellwig
2013-11-28 21:18   ` Dave Chinner
2013-11-29  8:05     ` Christoph Hellwig
2013-12-03 22:17       ` Dave Chinner
2013-12-03 22:43         ` Ben Myers
2013-12-04 11:00           ` Christoph Hellwig
2013-12-04 22:01             ` Ben Myers
2013-12-04 23:32             ` Dave Chinner [this message]

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=20131204233239.GF8803@dastard \
    --to=david@fromorbit.com \
    --cc=bpm@sgi.com \
    --cc=hch@infradead.org \
    --cc=rjohnston@sgi.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