On 29/08/2011 10:13, Paul Reeves wrote: > On Monday 29 August 2011 at 14:25 Michael Weissenbacher wrote: > >>> But if barriers are needed just to make journal commits safe on the disk >>> with write cache turned on this seems to be not directly related with >>> firebird databases - write cache ON will anyway break firebird database >>> in case of crash. Or may be this option actually deals with all data on >>> disk, not only journal? >> To my knowlege, barrier=1 only provides guarantees for the filesystem >> metadata. But in the way it's implemented in hardware a "barrier flush" >> currently in most (all?) configurations flushes all data. This could >> (and will) change in the future. >> > The default for ext3/4 is data=ordered and, from the kernel docs:
I read divergent things about this. Some says that ext3 default changed to writeback, others says it depends from a kernel configure option. > "All data are forced directly out to the main file system prior to its > metadata being committed to the journal." > > So presumably as long as data=ordered then a barrier flush will always imply > that all data is written to disc. > > Does that means that FW=ON (i.e., O_SYNC mode) doesn't guarantee that a commit reported as succeeded may really succeed if a fast power loss happens and the hard disk has a non-battery based cache and barriers are disabled? And considering that O_SYNC and barrier are on, does it implies that any page write will make the metadata flush, or something else must be done? Adriano ------------------------------------------------------------------------------ EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
