On Tue, Aug 16, 2011 at 04:07:38PM -0700, Jiaying Zhang wrote: > Good question. At the time when we checked in the code, we wanted to be > careful that it didn't introduce data corruptions that would affect normal > workloads. Apparently, the downside is that this code path doesn't get > a good test coverage. Maybe it is time to reconsider enabling this feature > by default. I guess we still want to guard it with a mount option given that > it doesn't work with certain options, like "data=journaled" mode and small > block size. What I'd like to do long-term here is to change things so that (a) instead of instantiating the extent as uninitialized, writing the data, and then doing the uninit->init conversion to writing the data and then instantiated the extent as initialzied. This would also allow us to get rid of data=ordered mode. And we should make it work for fs block size != page size. It means that we need a way of adding this sort of information into an in-memory extent cache but which isn't saved to disk until the data is written. We've also talked about adding the information about whether an extent is subject to delalloc as well, so we don't have to grovel through the page cache and look at individual buffers attached to the pages. And there are folks who have been experimenting with an in-memory extent tree cache to speed access to fast PCIe-attached flash. It seems to me that if we're careful a single solution should be able to solve all of these problems... - 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
