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