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@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
