On 29/08/2011 08:35, Alexander Peshkov wrote:
> В Вс., 28/08/2011 в 19:14 -0300, Adriano dos Santos Fernandes пишет:
>> After I bought a new machine, I reinstalled Ubuntu
Yes. Kernel is 2.6.38.
>> in new HDD with ext4
>> 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
> 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.
> 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.
> 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?
Is this "writecache" you're talking the one changeable by hdparm?
Here is another funny time:
ext4, barrier=1, data=ordered, vmware with file-based disk, guest is
Ubuntu 11.04, host is Windows 7
create database time: around 0.45s [compared to 2.8s of same config but