From: Eric Sandeen <sandeen@sandeen.net>
To: Ben Myers <bpm@sgi.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 0/2] xfs: defrag support for v5 filesystems
Date: Thu, 05 Sep 2013 15:03:20 -0500 [thread overview]
Message-ID: <5228E388.3060901@sandeen.net> (raw)
In-Reply-To: <5228E217.5080002@sandeen.net>
On 9/5/13 2:57 PM, Eric Sandeen wrote:
> On 9/5/13 2:34 PM, Ben Myers wrote:
>> Dave,
>>
>> On Wed, Sep 04, 2013 at 08:45:42AM +1000, Dave Chinner wrote:
>
> ...
>
>>> If people don't want CRCs, then we've still got a perfectly good v4
>>> filesystem format that they can use.
>>
>> People can still use v4 filesystem format, but the self describing metadata
>> includes checks that have value even without the crc.
>
> Perhaps, but unless there is *value* in turning them off, there is no reason
> to do so. See previous arguments about test matrix etc.
>
> Right now you suggest a different mechanism, but it doesn't actually
> exist at this point - at least not for end-to-end metadata integrity.
>
> crcs between hba & storage is a very different thing, and really not
> a substitute for xfs's object crcs. More below
>
> ...
>
>>> Guess what we do right now with CRC support?
>>>
>>> That's right: the existing CRC infrastructure is ready to support
>>> integrated, end-to-end T10 CRCs for metadata in the filesystem. All
>>> that is missing is the block layer interfaces and a few changes to
>>> the CRC code to do iterative per-sector CRCs rather than
>>> per-filesystem object CRCs.
>>
>> Yes! This is exactly what I would like to discuss.
>
> ...
>
> So if and when that is available, we could discuss whether or not
> there is any reason to disable crcs, right? Until then we're
> handwaving with no good rationale.
In fact, I think we can distill this even further. Even *with*
t10dif at the HBA level, the only reason I can see to turn off
per-object crcs is performance.
To make that argument, you should publish the performance numbers.
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-09-05 20:03 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 [this message]
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=5228E388.3060901@sandeen.net \
--to=sandeen@sandeen.net \
--cc=bpm@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 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.