On Fri, 9 Jun 2006, Alex Tomas wrote: > > I believe it's as stable as before until you mount with extents > mount option. That's always a possibility in theory, and almost never in practice. Btw, I don't care about extents _per_se_. I do care about the fact that people seem to think that code gets better as it supports more features. Not so. The whole logic of "code sharing is good" is a huge mistake. Shared code is not at all better than individual code snippets, and often much much worse. In particular, if the shared code has separate code-paths, not just twice as complicated: it's _more_ than twice as bad, since it introduces the conditionals _and_ it introduces the very real risk of the conditional being taken the wrong way by mistake. In contrast, the last time two different filesystems introduced bugs in each other was approximately "never". They simply don't modify each others code, they don't look at each others data structures, and they don't jump into each others routines. So two separate filesystems are _less_ to maintain than one big one. Even if there's a lot of code that -could- be shared. And no, extents in themselves aren't necessarily "the thing" that drives it from maintainable to unmaintainable. This crap grows over time. But I would _serious_ suggest that starting anew with a "new" filesystem, and taking the time to actually also get _rid_ of some of the baggage would quite likely be a good idea. Just as an example: ext3 _sucks_ in many ways. It has huge inodes that take up way too much space in memory. It has absolutely disgusting code to handle directory reading and writing (buffer heads! In 2006!). It's conditional indexing code is horrible. Its performance absolutely sucks when the journal is being drained or something. Are you going to improve on any of those _fundamnetal_ problems? Or are you going to make them worse? Hint: I'm betting you're not going to improve them by adding more features. Linus - 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
