On Mon, Jun 27, 2011 at 05:30:11PM +0200, Lukas Czerner wrote: > > I've found some. So although data=journal users are minority, there are > > some. That being said I agree with you we should do something about it > > - either state that we want to fully support data=journal - and then we > > should really do better with testing it or deprecate it and remove it > > (which would save us some complications in the code). > > > > I would be slightly in favor of removing it (code simplicity, less options > > to configure for admin, less options to test for us, some users I've come > > across actually were not quite sure why they are using it - they just > > thought it looks safer). Hmm... FYI, I hope to be able to bring on line automated testing for ext4 later this summer (there's a testing person at Google is has signed up to work on setting this up as his 20% project). The test matrix that I have him included data=journal, so we will be getting better testing in the near future. At least historically, data=journalling was the *simpler* case, and was the first thing supported by ext4. (data=ordered required revoke handling which didn't land for six months or so). So I'm not really that convinced that removing really buys us that much code simplification. That being siad, it is true that data=journalled isn't necessarily faster. For heavy disk-bound workloads, it can be slower. So I can imagine adding some documentation that warns people not to use data=journal unless they really know what they are doing, but at least personally, I'm a bit reluctant to dispense with a bug report like this by saying, "oh, that feature should be deprecated". 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
