25.10.2011 23:15, Dimitry Sibiryakov wrote:
>
> I would like to see information about field names in input XSQLDA fields.
> Should I create duplicate ticket as a feature request?
Feel free.
Dmitry
--
The demand for IT
>In other words: if you use Ext3 and you note performance regressions
>with this release, try disabling barriers ("barriers=0" mount option).
Don't you mean 'try being thankful that you finally have transactional
semantics, and try not to be too sore that you've been mugged for
years'?
This wou
Hello, All.
Why CORE-432 was closed with resolution "Won't fix"? I would like to see
information
about field names in input XSQLDA fields. Should I create duplicate ticket as a
feature
request?
--
SY, SD.
-
25.10.2011 14:39, Philippe Makowski wrote:
> in fact with theses settings, FW=OFF is safer than before
> safe enough to be the default ?
Even in the "paranoid mode" (MaxUnflushedWrites = 1) they still don't
guarantee the write order. So, if the crash happens while the
transaction is being commi
25.10.2011 12:39, Philippe Makowski wrote:
> in fact with theses settings, FW=OFF is safer than before
> safe enough to be the default ?
No. I'd say even more: these settings leads to problem on weak computers
when
periodical intensive i/o almost block all other FB activity.
--
SY, SD.
Dmitry Yemanov [2011-10-25 12:34] :
> 25.10.2011 14:24, Paul Reeves wrote:
>>
>> AFAICT, fsync only gets called if FW=ON. Or have I missed something?
>
> With FW=OFF, it's controlled by MaxUnflushedWrites and
> MaxUnflushedWriteTime.
>
in fact with theses settings, FW=OFF is safer than before
s
25.10.2011 14:45, Paul Reeves wrote:
> The documentation in firebird.conf (v2.5) indicates that this is disabled for
> posix.
It's disabled by default (setting = -1). But it does work if reconfigured.
Dmitry
--
The dem
On 25/10/2011 08:39, Vlad Khorsun wrote:
>> 25.10.2011 14:03, Adriano dos Santos Fernandes wrote:
>>
>>> 2) FW=OFF, and use fsync on COMMIT - pages will not be reordered, and
>>> when COMMIT happens they will be written to disk in order
>> I believe this is wrong assumption. Nobody guarantees that
On Tuesday 25 October 2011 at 12:34 Dmitry Yemanov wrote:
> 25.10.2011 14:24, Paul Reeves wrote:
> > AFAICT, fsync only gets called if FW=ON. Or have I missed something?
>
> With FW=OFF, it's controlled by MaxUnflushedWrites and
> MaxUnflushedWriteTime.
>
The documentation in firebird.conf (v2.
> 25.10.2011 14:03, Adriano dos Santos Fernandes wrote:
>
>> 2) FW=OFF, and use fsync on COMMIT - pages will not be reordered, and
>> when COMMIT happens they will be written to disk in order
>
> I believe this is wrong assumption. Nobody guarantees that OS will be
> flushing the dirty pages fro
25.10.2011 12:34, Dmitry Yemanov wrote:
> With FW=OFF, it's controlled by MaxUnflushedWrites and
> MaxUnflushedWriteTime.
Which are disabled everywhere except Windows.
--
SY, SD.
--
The demand for IT networking pr
25.10.2011 14:24, Paul Reeves wrote:
>
> AFAICT, fsync only gets called if FW=ON. Or have I missed something?
With FW=OFF, it's controlled by MaxUnflushedWrites and
MaxUnflushedWriteTime.
Dmitry
--
The demand for IT ne
25.10.2011 14:03, Adriano dos Santos Fernandes wrote:
> 2) FW=OFF, and use fsync on COMMIT - pages will not be reordered, and
> when COMMIT happens they will be written to disk in order
I believe this is wrong assumption. Nobody guarantees that OS will be
flushing the dirty pages from the file-s
On Tuesday 25 October 2011 at 12:03 Adriano dos Santos Fernandes wrote:
>
> 1) FW=ON - each page written by Firebird goes to disk immediately, in
> the order issued by Firebird
> 2) FW=OFF, and use fsync on COMMIT - pages will not be reordered, and
> when COMMIT happens they will be written to di
On 10/24/11 15:27, Damyan Ivanov wrote:
>> We had that port in FB1, but later cleaned it up. And I see no
>> reasons to return to it.
> I'd suggest to not put too much effort into that or any other port.
> Let people interested in the port submit patches. I hope at least
> there is an implement
On 10/25/11 14:03, Adriano dos Santos Fernandes wrote:
> On 25/10/2011 07:56, Paul Reeves wrote:
>> On Tuesday 25 October 2011 at 11:12 marius adrian popa wrote:
>>
>>> In other words: if you use Ext3 and you note performance regressions
>>> with this release, try disabling barriers ("barriers=0"
On 25/10/2011 07:56, Paul Reeves wrote:
> On Tuesday 25 October 2011 at 11:12 marius adrian popa wrote:
>
>> In other words: if you use Ext3 and you note performance regressions
>> with this release, try disabling barriers ("barriers=0" mount option).
> I can understand doing this for routine deskt
On 10/25/11 13:56, Paul Reeves wrote:
> On Tuesday 25 October 2011 at 11:12 marius adrian popa wrote:
>
>> In other words: if you use Ext3 and you note performance regressions
>> with this release, try disabling barriers ("barriers=0" mount option).
> I can understand doing this for routine deskto
On Tuesday 25 October 2011 at 11:12 marius adrian popa wrote:
>
> In other words: if you use Ext3 and you note performance regressions
> with this release, try disabling barriers ("barriers=0" mount option).
I can understand doing this for routine desktop work. It does make a
difference. But fo
if you feel slow downs with database access (inserts) with the new
kernel 3.1 and ext3 Filesystem barriers enabled by default in Ext3
http://kernelnewbies.org/Linux_3.1
Hard disks have a memory buffer were they temporally store the
instructions and data issued from the OS while the disk processe
20 matches
Mail list logo
