On Jun 09, 2006 10:13 +0100, Christoph Hellwig wrote: > the block numbers are't the big problem concerning scalability, there's > a lot more to it, like btree(-like) structures in the allocator, parallel > alloocator algorithms and a better allocation group concept. All of the allocator changes are already written and well tested, and gave ext3 a 30% performance improvement while at the same time reducing CPU usage by 50% - not trivial. See Holger Kiehl's post http://marc.theaimsgroup.com/?l=linux-kernel&m=114958967600822&w=4 > If you guys want big storage on linux please help improving the filesystems > design for that, e.g. jfs or xfs instead of showhorning it onto ext3 thus > both making ext3 less reliable for us desktop/small server users and not get > the full thing for the big storage people either. XFS = 108844 lines, and a complete mess to understand. ext3+jbd = 27749 lines (includes ~6000 lines extent/allocation changes) Also, ext3 is just much more robust in the face of on-disk corruption than xfs or jfs because of its "static" layout, and e2fsck is way better than the alternatives. Despite their "big storage" designs ext3 is still competitive in performance, especially with the allocation improvements. See also: http://marc.theaimsgroup.com/?l=ext2-devel&m=108194477207334&w=4 http://marc.theaimsgroup.com/?l=linux-fsdevel&m=110112879929869&w=4 http://samba.org/~tridge/xattr_results/xfs-ext3-tuning.png If the XFS or JFS maintainers want to fix their filesystems, they are free to do so, the ext3 maintainers (all of them, btw) want these changes. The extent code (prior to some minor cleanups for landing on the vanilla kernel) has already seen many millions of hours of testing in very heavy IO environments, so it isn't something that was just written. If extents aren't enabled it amounts to a couple of extra conditionals in the allocation path and basically no modifications to the existing code, so you can safely avoid this code if you feel the need to. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
