On Thu, Mar 11, 2010 at 10:38:25AM -0600, Eric Sandeen wrote: > Jan suggests that we not surprise users by having delalloc enabled when ext3 > is mounted with the ext4 driver. However there are other behavior differences > as well, mballoc behavior comes to mind at least. What about the 32000 subdir > limit? The block allocator behaviour does change, but not in user-visible fashion. And there have been times in the past when we've messed with the ext3's allocation algorithms (Mingming's reservation windows being the most recent example), and that falls pretty squarely into a non-user visible (aside from a performance increase) change. Breaking the subdir limit requires a feature flag (DIR_NLINK) so it's not something that would be seen when mounting an ext3-compatible file system using ext4. The reason why disabling delalloc by default when using ext4 to emulate ext3 may make sense is because it does have a potentially controversial impact with respect to applications which don't fsync() but which assumes that data blocks will magically be sync'ed to disk after five seconds. I disagree with that assumption, but the number of clueless application writers and users who have come to depend on it outnumber us by a fairly wide margin. > I guess my point here is I think we have completely crossed the line of a > coherent story of what ext4 is and how it's supported and tested; things are > feeling so tuning-knob-option-happy and full of caveats that our matrix looks > infinite from where I stand. > > This option won't be enabled on fedora or rhel, (and I don't mean to single out > this particular commit, it just got me started on this train of thought) > but I just wanted to air a general concern that ext4 not try to be 10,000 different > things to all people, and focus on something testable, documentable, and supportable. > > For myself and the distros I work on, I strongly prefer to limit things to: > > a) filesystems mkfs'd and mounted as ext4 > b) ext3 filesystems migrated according to a very specific set of steps > > All these other sub-cases and what-ifs and except-unless behaviors really > muddy the water, IMHO. I think it's completely fair that Red Hat picks a subset of features to concentrate their testing and support on. And I am very sympathetic to the concerns of our exploding test matrix if we want to have complete coverage. At the same time, there is some benefit in growing our community by support some other alternatives, which might not be that useful in the general case, or for an enterprise distro. So as we don't contaminate core code, and we can keep the code vaguely maintainable, a certain amount of flexibility and options is good. I do think that it was highly reassuring to some key users of our userbase because we supported the use case of people who wanted to be able to use unmigrated ext2/3 file systems with the ability go back to ext2/3 afterwards. And the fact that in general e2fsck is more strict about file system consistency issues than the kernel, and e2fsck shows a clean file system after mounting an unmodified ext2/3 file system does reassure me. (And I will perform, from time to time, XFSQA tests using an ext2-compatible file system mounted using ext4). So that's why I was pretty comfortable with the CONFIG_EXT4_USE_FOR_EXT23 option. And hey, users who used it quickly found a problem how we calculated indirect-mapped metablock reservations much more quickly than if we didn't have this option --- and this bug is one that would have eventually hit your "migrated ext3 file systems" case, except much more rarely, so the end result was a more robust file system. So at least in this case, I think it was actually a net benefit. Regards, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
