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
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
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.