Firebird

>      Look at isc_prepare_transaction2() API. It could attach *any* application-specific
> message to the local transaction before actual commit. TM could pass XID + "something
> to identify this part of distributed transaction" into isc_prepare_transaction and later read
> this info back from RDB$TRANSACTIONS at recovery phase, if necessary. And\or TM
> could store above "something to identify this part of distributed transaction" + local TxID
> of every part of distributed transaction into its own storage before start distributed commit
> (to identify record at RDB$TRANSACTIONS later at recovery phase).
>
>      Look also at isc_reconnect_transaction() API which allows to re-connect to the in-limbo
> transaction at recovery phase and finally commit or rollback it.

This code should be already working in Jaybird since day 0 (David Jencks 
implemented it in the first version of the driver). The recovery process 
uses message to query the in-limbo transactions, is able to join them 
and is able to commit or rollback them.

However, if I remember correctly, the requirement to support transaction 
independent from the attachment came from the fact that TM may be asked 
to activate a transaction that "belongs" to the attachment that is being 
currently used and is associated with a different transaction. Here we 
talk about normal processing, not the recovery process. I guess the main 
issue here is the synchronization of the wire communication, so that two 
transactions are properly interleaved and server is able to handle the 
communication. Another issue here is that when a non-recoverable error 
happens (e.g. request synchronisation error), we have to kill all 
transactions that belong to that attachment, even if only one is in trouble.

But this requirement is so old, that I do not remember exact details. 
The only thing I remember is that it becomes obvious when somebody 
starts refactoring the XA part (which is one of the core layers there). 
That happened to me when I refactored that code few years ago, that's 
happening to Mark right now. :)

Roman

>>      Look at isc_prepare_transaction2() API. It could attach *any* application-specific
>> message to the local transaction before actual commit. TM could pass XID + "something
>> to identify this part of distributed transaction" into isc_prepare_transaction and later read
>> this info back from RDB$TRANSACTIONS at recovery phase, if necessary. And\or TM
>> could store above "something to identify this part of distributed transaction" + local TxID
>> of every part of distributed transaction into its own storage before start distributed commit
>> (to identify record at RDB$TRANSACTIONS later at recovery phase).
>>
>>      Look also at isc_reconnect_transaction() API which allows to re-connect to the in-limbo
>> transaction at recovery phase and finally commit or rollback it.
> 
> This code should be already working in Jaybird since day 0 (David Jencks 
> implemented it in the first version of the driver). The recovery process 
> uses message to query the in-limbo transactions, is able to join them 
> and is able to commit or rollback them.

    Very good :)
 
> However, if I remember correctly, the requirement to support transaction 
> independent from the attachment came from the fact that TM may be asked 
> to activate a transaction that "belongs" to the attachment that is being 
> currently used and is associated with a different transaction. Here we 
> talk about normal processing, not the recovery process. I guess the main 
> issue here is the synchronization of the wire communication, so that two 
> transactions are properly interleaved and server is able to handle the 
> communication. 

        Before v2.1 it should be able to handle it properly. Since v2.1 it must be able to handle 
it properly. I mean - it should not hung and handle "asyncronous" TM call after processing of 
current "syncronous" call on the same attachment.

> Another issue here is that when a non-recoverable error 
> happens (e.g. request synchronisation error), 

    Hmm... is it unrecoverable error ? BTW, request synchronisation error could happen only 
at fetching records, iirc...

> we have to kill all 
> transactions that belong to that attachment, even if only one is in trouble.

    Even if we have to kill all transactions - what is the problem for TM ?
 
> But this requirement is so old, that I do not remember exact details. 

:)

> The only thing I remember is that it becomes obvious when somebody 
> starts refactoring the XA part (which is one of the core layers there). 
> That happened to me when I refactored that code few years ago, that's 
> happening to Mark right now. :)

    Let's solve this puzzle together ;)

Regards,
Vlad

On Mon, Aug 29, 2011 at 5:57 PM, Vlad Khorsun
<hvlad@...:

>
> > Another issue here is that when a non-recoverable error
> > happens (e.g. request synchronisation error),
>
>    Hmm... is it unrecoverable error ? BTW, request synchronisation error
> could happen only
> at fetching records, iirc...


Between a prepare and a commit, the only irrecoverable errors I know of are
disk errors and communication errors.  All data is already on disk and there
is no additional processing (give or take post-commit triggers). But there
could be a fatal disk error in changing the transaction state, or the
machine that ran that part of the transaction could have dropped into the
San Andreas  fault.

Both happy thoughts.

Cheers,

Ann

>

В Вс., 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.

В Пн., 29/08/2011 в 07:47 -0300, Adriano dos Santos Fernandes пишет:
> On 29/08/2011 06:27, Paul Reeves wrote:
> > On Monday 29 August 2011 at 11:05 marius adrian popa wrote:
> >
> >
> >> you are not the only one that observed db/vm performance issues with ext4
> >> maybe you need to mount it with data=writeback
> >>
> >> http://blog.smartlogicsolutions.com/2009/06/04/mount-options-to-improve-ext
> >> 4-file-system-performance/
> >>
> > Yes, data=writeback sounds really clever. To quote:
> >
> > 	Data ordering is not preserved, data may be written into the main file
> >     system after its metadata has been committed to the journal.
> 
> That's not everybody opinions:
> 
> http://www.linux-magazine.com/Online/News/Linus-Torvalds-Upset-over-Ext3-and-Ext4
> 
> Kernel chief Torvalds is hardly convinced by these arguments. In his 
> view, "if you write your metadata earlier (say, every 5 sec) and the 
> real data later (say, every 30 sec), you're actually more likely to see 
> corrupt files than if you try to write them together... This is why I 
> absolutely detest the idiotic ext3 writeback behavior. It literally does 
> everything the wrong way around -- writing data later than the metadata 
> that points to it. Whoever came up with that solution was a moron. No 
> ifs, buts, or maybes about it."

+1
Certainly writing metadata before data is nonsense.

On Monday 29 August 2011 at 12:47 Adriano dos Santos Fernandes wrote:

> On 29/08/2011 06:27, Paul Reeves wrote:
> > On Monday 29 August 2011 at 11:05 marius adrian popa wrote:
> >> you are not the only one that observed db/vm performance issues with
> >> ext4 maybe you need to mount it with data=writeback
> >> 
> >> http://blog.smartlogicsolutions.com/2009/06/04/mount-options-to-improve-
> >> ext 4-file-system-performance/
> > 
> > Yes, data=writeback sounds really clever. To quote:
> > 	Data ordering is not preserved, data may be written into the main file
> >     system after its metadata has been committed to the journal.
> 
> That's not everybody opinions:
> 
> http://www.linux-magazine.com/Online/News/Linus-Torvalds-Upset-over-Ext3-an
> d-Ext4
> 

Adriano, I'm not sure why you replied to my comment - I was making the same 
point as Torvalds, but with irony instead of insulting morons :-)


Paul
-- 
Paul Reeves
http://www.ibphoenix.com
Specialists in Firebird support

В Пн., 29/08/2011 в 14:16 +0200, Paul Reeves пишет:
> On Monday 29 August 2011 at 12:47 Adriano dos Santos Fernandes wrote:
> 
> > On 29/08/2011 06:27, Paul Reeves wrote:
> > > On Monday 29 August 2011 at 11:05 marius adrian popa wrote:
> > >> you are not the only one that observed db/vm performance issues with
> > >> ext4 maybe you need to mount it with data=writeback
> > >> 
> > >> http://blog.smartlogicsolutions.com/2009/06/04/mount-options-to-improve-
> > >> ext 4-file-system-performance/
> > > 
> > > Yes, data=writeback sounds really clever. To quote:
> > > 	Data ordering is not preserved, data may be written into the main file
> > >     system after its metadata has been committed to the journal.
> > 
> > That's not everybody opinions:
> > 
> > http://www.linux-magazine.com/Online/News/Linus-Torvalds-Upset-over-Ext3-an
> > d-Ext4
> > 
> 
> Adriano, I'm not sure why you replied to my comment - I was making the same 
> point as Torvalds, but with irony instead of insulting morons :-)

Paul, telling true I've also not understood a humor. May be that's
because I and Adriano are not native english speakers?

On Monday 29 August 2011 at 14:22 Alexander Peshkov wrote:

> 
> Paul, telling true I've also not understood a humor. May be that's
> because I and Adriano are not native english speakers?
> 

Probably :-) I can't say for other langauges but irony is used a lot in 
english. When we say someone or something is really clever we usually mean the 
opposite. This way we avoid actually saying that data=writeback is idiotic and 
the inventor of this was a moron. Although I have to say that the Torvalds 
quote made me laugh.


Paul
-- 
Paul Reeves
http://www.ibphoenix.com
Specialists in Firebird support

It´s semi OT, but what about using XFS?

Seems to be much better in terms of speed, not sure in terms of reliability:
http://www.slideshare.net/ibsurgeon/firebird-25-benchmark-by-tsutomu-hayashi-tomneko

Regards!

El 28/08/2011 07:14 p.m., Adriano dos Santos Fernandes escribió:
> All,
>
> After I bought a new machine, I reinstalled Ubuntu 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?
>
> Does ext4 just f*ks?
>
> Is ext3 good just until you need what it markets, i.e., you should pray
> for no hardware crashes or power loss?
>
> What about some new parameter to ignore FW=on for who just don't care?
> (tests, development, etc)
>
>
> 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
>
>

-- 
Jorge Andrés Brugger
Informática
DASU - Obra Social del Personal de la Universidad Nacional de la Patagonia
Comodoro Rivadavia, Chubut, Argentina
Teléfono (0297) 446-4444 int. 103
Correo electrónico: jbrugger@...
Website: http://www.dasu.com.ar

> 
> 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.

hth,
Michael

> 
> Adriano, I'm not sure why you replied to my comment - I was making the same 
> point as Torvalds, but with irony instead of insulting morons :-)
> 
> 
> Paul

I guess he was missing the </irony> tag :-)

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

On Monday 29 August 2011 at 13:35 Alexander Peshkov wrote:

> 
> Tested CREATE DATABASE on my old box. To avoid disk fragmentation
> effects database was always created on new shining partition.
> 

I've found different results doing a large db restore. ext4 came out better 
than ext3. I also found ext4 to be better than xfs. The tests were optimised 
for large files, but I didn't consider barriers. :-( 

I guess I'll have to go and extend the test suite a bit and report back.


> To be politically correct - we should better not recommend people use
> ext4 for databases.

I'm not so sure. AFAIK, the default for ext4 is barrier=1 and the default for 
ext3 is barrier=0. In both cases 'data=ordered' is the default. My impression 
is that ext4 is faster and safer than ext3.

But when doing tests it is important to understand  what the defaults are. 
There are defaults set in the kernel and distros can change those defaults. I 
did some other tests on disc i/o recently and it took me a long while before I 
discovered the 'sync' option. If ext3 is mounted with the default async then 
the test results will be meaningless because writes will be cached. 

I don't know if sync is relevant to ext4. My man8 page for mount (from 
opensuse 11.3) says sync is only relevant to ext2, ext3, fat, vfat and ufs, 
but that may just be an error of omission.

I also discovered that setting write cache = off at the disc level may not be 
persistent across reboots. So, to be sure, every test run needs to specify 
this at the start of the run.


Paul
-- 
Paul Reeves
http://www.ibphoenix.com
Specialists in Firebird support

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

On 29/08/2011 10:24, Paul Reeves wrote:
> On Monday 29 August 2011 at 13:35 Alexander Peshkov wrote:
>
>> Tested CREATE DATABASE on my old box. To avoid disk fragmentation
>> effects database was always created on new shining partition.
>>
> I've found different results doing a large db restore. ext4 came out better
> than ext3. I also found ext4 to be better than xfs. The tests were optimised
> for large files, but I didn't consider barriers. :-(
>
> I guess I'll have to go and extend the test suite a bit and report back.
>
AFAIK restore happens with FW=OFF, i.e., without O_SYNC.

The main problem I see with ext4 is when O_SYNC is used.


Adriano

On Monday 29 August 2011 at 15:30 Adriano dos Santos Fernandes wrote:

> On 29/08/2011 10:24, Paul Reeves wrote:
> > On Monday 29 August 2011 at 13:35 Alexander Peshkov wrote:
> >> Tested CREATE DATABASE on my old box. To avoid disk fragmentation
> >> effects database was always created on new shining partition.
> > 
> > I've found different results doing a large db restore. ext4 came out
> > better than ext3. I also found ext4 to be better than xfs. The tests
> > were optimised for large files, but I didn't consider barriers. :-(
> > 
> > I guess I'll have to go and extend the test suite a bit and report back.
> 
> AFAIK restore happens with FW=OFF, i.e., without O_SYNC.


Yes, I know. So in essence I was testing FW=OFF. The results are still valid 
though, as long as the context is understood. Unfortunately it is not easy to 
understand the context as there are so many variables and the defaults are not 
consistent.  


Paul
-- 
Paul Reeves
http://www.ibphoenix.com
Specialists in Firebird support

On Monday 29 August 2011 at 15:27 Adriano dos Santos Fernandes wrote:

> > 
> > 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.

I haven't updated my kernel documentation since May 2010 but it seems 
consistent  with the info in these links:

 http://www.mjmwired.net/kernel/Documentation/filesystems/ext3.txt
 http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt

Both say that the kernel default is data=ordered. However, distros can change 
this, so it is important to double check. The simplest way to do that is with:

  cat /proc/mounts


> >    "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?

That is how I understand it. Each level seems to play smoke and mirrors. If 
just one level does asynchronous writes then all timings will be wrong and 
there is a risk to data integrity.

The levels are 

Application - we can set FW=ON or OFF. If ON the we are saying write 
everything to disc immediately. If FW=OFF then we see a massive performance 
gain on small test runs (especially if super* is used.)

Filesystem - ext3 (and others) are mounted async by default (at least for 
opensuse). I've done disc i/o tests with the partition mounted async that show 
anomalies for disc iops. The only way to remove the anomalies was with 
mounting with sync. I had previously mounted with barrier=1 but that was 
insufficent. (Of course FW=ON).

Disc drive - Modern consumer drives are shipped with write cache = on. In 
theory the capacitors store sufficient energy to flush the cache to disc in 
event of power failure. Either way, if write caching is on then test results 
will be skewed. If the cache is not saturated then tests will appear to be 
quick (but data not actually written to disk). If the cache is saturated then 
results for test B will be distorted by the delayed writes from test A.


> 
> 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?
> 

Hmmm. I think I've answered that in the section above. One thing is for sure - 
you know that the writes are synchronous when the performance drops massively 
:-)


Paul
-- 
Paul Reeves
http://www.ibphoenix.com
Specialists in Firebird support

В Пн., 29/08/2011 в 16:11 +0200, Paul Reeves пишет:

> The levels are 
> 
> Application - we can set FW=ON or OFF. If ON the we are saying write 
> everything to disc immediately. If FW=OFF then we see a massive performance 
> gain on small test runs (especially if super* is used.)
> 
> Filesystem - ext3 (and others) are mounted async by default (at least for 
> opensuse). I've done disc i/o tests with the partition mounted async that show 
> anomalies for disc iops. The only way to remove the anomalies was with 
> mounting with sync. I had previously mounted with barrier=1 but that was 
> insufficent. (Of course FW=ON).
> 

It seems that you've got slightly strange results here. 
>From what I've always noticed sync/async in mount specify default
behaviour, where async may be overridden using O_SYNC in open(). 

For example - if you mount a disk with database shadow sync, shadow will
be OK after power failure even when primary database file is corrupted.
I've seen this effect many times in one funny environment, where UPS
used to turn of all power for unknown reason.

On 29/08/2011 08:35, Alexander Peshkov wrote:
> В Вс., 28/08/2011 в 19:14 -0300, Adriano dos Santos Fernandes пишет:
>> All,
>>
>> After I bought a new machine, I reinstalled Ubuntu
> 11.04?

Yes. Kernel is 2.6.38.


>>   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?

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 
non-virtualized]


Adriano

В Пн., 29/08/2011 в 13:09 -0300, Adriano dos Santos Fernandes пишет:
> On 29/08/2011 08:35, Alexander Peshkov wrote:
> > В Вс., 28/08/2011 в 19:14 -0300, Adriano dos Santos Fernandes пишет:
> >> All,
> >>
> >> After I bought a new machine, I reinstalled Ubuntu
> > 11.04?
> 
> Yes. Kernel is 2.6.38.
> 

We have same test environments :)
Linux fbs 2.6.38-11-generic #48-Ubuntu SMP Fri Jul 29 19:02:55 UTC 2011
x86_64 x86_64 x86_64 GNU/Linux


> 
> >> 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?
> 
> Is this "writecache" you're talking the one changeable by hdparm?
> 

It's switch -W of 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 
> non-virtualized]

Suppose all caching is done by NTFS.