All, Let's remember the problem I initially observed. By default ext4 uses barriers and that makes it much slower than ext3 (when ext3 wasn't using barriers by default).
But it slower only whens FW=ON. With FW=OFF there is almost no difference. Barriers are supposed to act on file's metadata only, but the speedy problem we see don't make that appear to be true. Firebird don't use O_SYNC but O_DSYNC instead. O_DSYNC is supposed to sync the data and only the metadata necessary to retrieve the data correctly. O_DSYNC and O_SYNC is not always different on the implementation, but at least in Kernel 2.6.38 the implementation are surely different and O_DSYNC is faster. So considering a database which is already preallocated on the filesystem and Firebird don't create any new file pages, barriers would not influence the performance. But it's slower even on this condition. So I think not everything is well know on this problem, but I did some tests. A thing I saw is that opening a file with O_DSYNC and opening a file without it but calling fdatasync after each write has almost equal performance. I really don't know well how Firebird does the page precedence graph, but if we could write all "independent" (say, the ones with the order they're write didn't matter) then call fdatasync and continues, would be much better than O_DSYNC mode. Is it possible? How generally is that precedence graph, does it have to many "independent" pages on it? Adriano ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
