> > My basic impression is that the use of "data=journalled" can help > > reduce the risk (slightly) of serious corruption to some kinds of > > databases when the application does not provide appropriate syncs > > or journalling on its own (IE: such as text-based Wiki database files). Yes, although if the application has index files that have to be updated at the same time, there is no guarantee that the changes that survive after a system failure (either a crash or a power fail), unless the application is doing proper application-level journalling or some other structured. > To sum up, the only additional guarantee data=journal offers against > data=ordered is a total ordering of all IO operations. That is, if you do a > sequence of data and metadata operations, then you are guaranteed that > after a crash you will see the filesystem in a state corresponding exactly > to your sequence terminated at some (arbitrary) point. Data writes are > disassembled into page-sized & page-aligned sequence of writes for purpose > of this model... data=journal can also make the fsync() operation faster, since it will involver fewer seeks (although it will require a greater write bandwidth). Depending on the write bandwidth, you really need to benchmark things to be sure, though. - 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
