В Вс., 28/08/2011 в 19:14 -0300, Adriano dos Santos Fernandes пишет: > All, > > After I bought a new machine, I reinstalled Ubuntu
11.04? > in new HDD with ext4 > filesystem. > > While the new machine has much better CPU than the old one, I noticed > the build being very slow where Firebird was creating databases. > > I found that mounting the ext4 partition with barrier=0 parameter > decreased the performance from more than 2 minutes to less than 50s in > the build. > > But changing this parameter seems to not make ext4 at least safe as > ext3. So I reverted it and adjust the build to turn FW=off for the > internal databases. That didn't become fast as barrier=0, but was > acceptable (around 1 minute). > > Now I tried to run tcs and saw it's completely unpractical. So I started > to test just "create database" performance. > > The numbers are around this: > > ntfs: 0.2s > ext3 default (barrier=0): 0.1s > ext3 (barrier=1): 0.8s > ext4 default (barrier=1): 2.8s > > I removed the O_SYNC flag in posix.cpp and it makes ext4 similar to ext3. > > So I have some questions: > > Are we doing something wrong? > In 'man mount' I see: Write barriers enforce proper on-disk ordering of journal commits, making volatile disk write caches safe to use, at some performance penalty. 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? Tested CREATE DATABASE on my old box. To avoid disk fragmentation effects database was always created on new shining partition. writecache=OFF ext3 barrier=0 1.084s ext3 barrier=1 1.063s ext4 barrier=0 3.392s ext4 barrier=1 3.380s As expected - FS ignores barriers when cahce is off. writecache=ON ext3 barrier=0 0.388s ext3 barrier=1 1.023s ext4 barrier=0 0.410s ext4 barrier=1 1.884s In mode always recommended by us for FB databases, barriers make no effect. What is interesting to know - does that fance barriers effect only syslog or all filesystem write safety? > Does ext4 just f*ks? To be politically correct - we should better not recommend people use ext4 for databases. > Is ext3 good just until you need what it markets, i.e., you should pray > for no hardware crashes or power loss? As far as I can see ext3 is nice with write cache turned off too. Certainly disk write cache makes it work faster, but we know the price of that speed. > What about some new parameter to ignore FW=on for who just don't care? > (tests, development, etc) Parameter is not good idea I think. May be environment option... But certainly it's better to use correct filesystem for databases. ------------------------------------------------------------------------------ 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
