Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Lars Ellenberg wrote: > On Thu, Jul 03, 2008 at 09:48:49PM +0200, H.D. wrote: >> Eric Marin wrote: >>> a quick question for the filesystems experts : I'd like to mount an >>> EXT3 partition with the 'data=journal' option, for some tests. This >>> partition is in use by DRBD (cluster of two nodes). >> To my knowledge there is no reason to use data=journal. It does not >> provide any (safety) benefits over data=ordered. > > and usually, there are performance hits, > as all file data has to be written twice now as well, > once to the journal, and then to the final location. I've worked with people who claimed the performance hit as well, so I ran iozone benchmarks to see what the truth was. I tend to like ext3 with data=journal on /var/log because I've found that after a system crash the logs might have something useful in them rather than just garbage. Yes, in this regard data=journal really does make a difference. When I looked at the performance characteristics (I don't have the numbers now) the difference between data=journal and data=ordered was pretty small. It would only make a difference if you were writing large amounts of data very quickly to very large files (several gigabytes). In the scenario that I was researching (/var/log) I reasoned that *if* the performance hit of data=journal would be felt then the system had far *far* larger problems than disk write performance. Ie the disk would be filling up with gigantic log files *extremely* quickly. > but occasionally, there _may_ be performance benefits from using > data=journal, > e.g. if you have sporadic heavily radom write access > (as this would be converted to basically sequential writes to the > journal, and then moved to final location once the sporadic activity has > stopped), > or when you have many small short-lived (spool) files, like on a busy > smtp relay for the spool file system, because many of the files are > deleted before they ever reach their final location, so they would again > only be written once, and meta data, file data and journal updates are > localised again into the same "hot" section on disk. > you want to use the maximum journal size in this case, > which is 400MB for ext3 iirc. > > but for "normal" file server or data base usage, > data=journal will cause a performance hit, > and no gain in reliability. >