On 9/16/13 8:04 PM, Dave Chinner wrote: > On Wed, Sep 11, 2013 at 09:21:59AM -0700, Christoph Hellwig wrote: >> On Tue, Sep 10, 2013 at 01:35:47AM +1000, Dave Chinner wrote: >>> The test matrix of having to test everything on v4 and v5 is just >>> nasty, especially if we are talking about prototyping code. I'd much >>> prefer to bring things to v5 filesytsems where we have much lower >>> exposure and risk of corruption problems, and then when we know it's >>> solid because of the QA we've done on it, then we can expose the >>> majority of the XFS userbase to it by bringing it back to v4 >>> filesystems. >> >> I think the test matrix is a reason for not enabling this only on v5 >> filesystems. > > You're assuming that someone is doing lots of QA on v4 filesystems. > Most of my attention is focussed on v5 filesystems and compared to > the amount of v5 QA I'm doing, there is very little v4 QA. All my > development and prototyping is being done on v5 filesystems, and the > code I post indicates that. Red Hat QE is doing quite a lot of testing of V4 at this point, although not on totally bleeding-edge kernels. > I'm not about to propose new features for v4 filesystems if I > haven't tested them robustly. And, in many cases, the new features > I'm proposing require a new filesystem to be made (like this one > does because of the inode alignment requirement) and userspace tool > support, and so it's going to be months (maybe a year) before > userspace support is in the hands of distro-based users. > > People testing v5 filesystems right now are handrolling their > userspace code, and so they are following the bleeding edge of both > user and kernel space development. They are not using the bleeding > edge to test new v4 filesystem features. > > Given this, it makes sense to roll the v5 code first, then a > kernel release or 2 later roll in the v4 support once the v5 code > has been exposed and we've flushed out the problems. It minimises > our exposure to filesystem corruption issues, it gets the code into > the hands of early adopters and testers quickly, and it gets rolled > back into v4 filesystems in the same timeframe as distros will be > picking up the feature in v5 filesystems for the first time. > > Nobody has yet given a technical reason why such a careful, staged > approach to new feature rollout for v4 filesystems is untenable. All > I'm hearing is people shouting at me for not bringing new features > to v4 filesystems. Indeed, my reasons and plans to bring the > features to v4 in the near future are being completely ignored to > the point of recklessness... That sounds perfectly reasonable to me; from your original RFC it wasn't clear to me that that was the plan (stage it & roll it out for V4 later). >> Large inodes are an old and supported use case, although >> probably not as heavily tested as it should. By introducing two >> different large inode cases we don't really help increasing test >> coverage for a code path that is the same for v4 and v5. > > I think you've got it wrong - 512 byte inodes have not been > regularly or heavily tested until we introduced v5 filesystems. Gluster users have been advised to use 512-byte inodes for quite some time, actually. (http://www.gluster.org/community/documentation/index.php/QuickStart) So there is some real-world coverage, and presumably QE as well. I understand your valid concerns (snipped below as well) but let's not overstate the case either; V4 and 512-byte are both seeing some coverage even today. -Eric _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
