From: Dave Chinner <david@fromorbit.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Ben Myers <bpm@sgi.com>, xfs@oss.sgi.com
Subject: Re: [PATCH 0/2] xfs: defrag support for v5 filesystems
Date: Fri, 6 Sep 2013 13:34:40 +1000 [thread overview]
Message-ID: <20130906033440.GC23571@dastard> (raw)
In-Reply-To: <5228E217.5080002@sandeen.net>
On Thu, Sep 05, 2013 at 02:57:11PM -0500, Eric Sandeen wrote:
> On 9/5/13 2:34 PM, Ben Myers wrote:
> > That is enough to go
> > on for starting a discussion. Insofar as supporting such a feature might
> > require interface changes to the existing work, I think we should discuss what
> > they might look like before finalizing the mkfs.xfs interfaces in a way that we
> > might find to be incompatible later. If after some discussion we find that
> > this can be done without interface changes that will gate removal of the
> > experimental tag... then it won't gate.
>
> It is incumbent on SGI to explain why they want to make it optional.
> There is no alternative design; if and when there is one, that's the time
> to make another configuration knob.
>
> I see 2 possible reasons you would want it to be configurable. The first
> seems least stated but most likely:
>
> 1) You have performance concerns.
>
> - you need to show us the numbers if that's the case so we can discuss facts
>
> 2) You think T10dif will make it unnecessary
>
> - t10dif in hardware gives you EIO, not corruption detection & recovery
> - end-to-end t10dif with xfs at the "app" layer might be an option, but
> - nobody has written that, and
> - the only reason to turn off the object crcs at that point is perf, and
> - again, we'd need to start with performance numbers.
Actually, t10-dif is not equivalent to v5 filesystem object CRCs at
all. The filesystem object can span multiple sectors, and while
t10-dif can only guarantee individual sector contents are correct,
it cannot guarantee that all the sectors in a given filesystem
object are up to date.
Why is this important? Because XFS metadata can span multiple
filesystem blocks and hence be discontiguous and require multiple
IOs to write to disk. Hence we can have regions of the object that
have different ages (i.e. partially written) and t10-diff based CRCs
*cannot detect this*.
So, even with end-to-end t10-dif CRCs, we still need filesystem
object level CRCs to guarantee that the objects are completely
internally consistent....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-09-06 3:35 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 ` [PATCH 0/2] xfs: defrag support for v5 filesystems Ben Myers
2013-09-03 22:45 ` 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 [this message]
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=20130906033440.GC23571@dastard \
--to=david@fromorbit.com \
--cc=bpm@sgi.com \
--cc=sandeen@sandeen.net \
--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