On Tue, Aug 20, 2013 at 09:29:17AM -0500, Mark Tinguely wrote: > I repeat, if you have technical concerns for the feature's > implementation and its impact on v4 filesystems because it uses > common directory code, then it should be held back for more testing. I missed this comment. Mark, I'm really concerned that SGI is taking the stance that the dtype code is fully working unless otherwise proven to have problems. That is a dangerous approach to take for new code and new on-disk formats - it should be considered with suspicion and paranoia until enough testing has been done to negate those concerns. The reason I only proposed this for v5 superblocks is to enable wider testing and get us to the point where we are not concerned anymore about it before we say it is ready for production deployment. I have technical concerns that arise once the feature bit it enabled, not when it is disabled. Those technical concerns center around off-by-one and alignment issues as a result of increasing the dirent size when the feature bit is enabled - they pack differently into the directory structure and hence will exercise allocation, freespace and logging differently. See my previous comments about how hard the directory code is to test and validate - that's why I want to enable in V5 first so we can shake out problems over a wider (but still constrained) user base that understand that EXPERIMENTAL means that they might still be corruption bugs lurking. Again, as I've said all along - enabling the feature on v4 filesystems is not a technical problem - it's a process and support problem. If I thought that this code was ready for widespread production deployment then I would have no hesitation to add v4 support, but it's simply not at that stage yet. We need wider test and deployment coverage to get the new feature to that stage. Which leads to the "then it should be held back for more testing" comment. We've discussed this before - almost a year ago now - when SGI stated that they wouldn't accept any new code in the xfsdev tree unless it was proven to be regression free. That was unacceptable then and to apply it to the v5 dirent code is no different. We need wider testing of these changes before it is production ready, and so holding it back until it's proven to be OK for production deployment in v4 filesystems is placing us in a catch-22 and as such is a similarly an unacceptable outcome. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
