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
|