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: "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. Paul -- Paul Reeves http://www.ibphoenix.com Specialists in Firebird support ------------------------------------------------------------------------------ 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
