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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox