> On 11/17/11 15:37, Vlad Khorsun wrote:
>>> On 11/17/11 14:14, Adriano dos Santos Fernandes wrote:
On 17/11/2011 07:52, Dmitry Yemanov wrote:
> The only way to guarantee ordered writes is to flush individual pages
> and this is what FW=ON does.
Or to flush group of independent p
On 11/17/11 15:23, Adriano dos Santos Fernandes wrote:
> On 17/11/2011 09:19, Alex Peshkoff wrote:
>> On 11/17/11 14:14, Adriano dos Santos Fernandes wrote:
>>> On 17/11/2011 07:52, Dmitry Yemanov wrote:
The only way to guarantee ordered writes is to flush individual pages
and this is
17.11.2011 15:37, Vlad Khorsun wrote:
> And, note, most heavy case (flush on commit) is already optimized.
With FW=ON, it's optimized only for better write order (less HDD head
movements). But AFAIU we're talking here about batched writes instead of
singleton writes.
Dmitry
-
On 11/17/11 15:37, Vlad Khorsun wrote:
>> On 11/17/11 14:14, Adriano dos Santos Fernandes wrote:
>>> On 17/11/2011 07:52, Dmitry Yemanov wrote:
The only way to guarantee ordered writes is to flush individual pages
and this is what FW=ON does.
>>> Or to flush group of independent pages a
> On 11/17/11 14:14, Adriano dos Santos Fernandes wrote:
>> On 17/11/2011 07:52, Dmitry Yemanov wrote:
>>> The only way to guarantee ordered writes is to flush individual pages
>>> and this is what FW=ON does.
>> Or to flush group of independent pages at once, like I proposed. I think
>> this can
On 17/11/2011 09:19, Alex Peshkoff wrote:
> On 11/17/11 14:14, Adriano dos Santos Fernandes wrote:
>> On 17/11/2011 07:52, Dmitry Yemanov wrote:
>>> The only way to guarantee ordered writes is to flush individual pages
>>> and this is what FW=ON does.
>> Or to flush group of independent pages at
On 11/17/11 14:14, Adriano dos Santos Fernandes wrote:
> On 17/11/2011 07:52, Dmitry Yemanov wrote:
>> The only way to guarantee ordered writes is to flush individual pages
>> and this is what FW=ON does.
> Or to flush group of independent pages at once, like I proposed. I think
> this can be a
> Dmitry Yemanov [2011-10-25 17:55] :
>> 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,
17.11.2011 14:14, Adriano dos Santos Fernandes wrote:
> Or to flush group of independent pages at once, like I proposed.
Sure. I was speaking about the current code only.
Dmitry
--
All the data continuously generated i
Adriano dos Santos Fernandes [2011-11-17 11:14] :
> On 17/11/2011 07:52, Dmitry Yemanov wrote:
>> The only way to guarantee ordered writes is to flush individual pages
>> and this is what FW=ON does.
>
> Or to flush group of independent pages at once, like I proposed. I think
> this can be a gr
Dmitry Yemanov [2011-11-17 10:52] :
> The only way to guarantee ordered writes is to flush individual pages
> and this is what FW=ON does.
and that's what cost a lot
so without WAL, no clear guarantied solution
but WAL is another problem
I see
---
On 17/11/2011 07:52, Dmitry Yemanov wrote:
> The only way to guarantee ordered writes is to flush individual pages
> and this is what FW=ON does.
Or to flush group of independent pages at once, like I proposed. I think
this can be a great improvement for FW=ON.
Adriano
--
17.11.2011 13:25, Philippe Makowski wrote:
> hum
> would it be hard to have it in the good order
Impossible, IMHO. The entire idea of the combined writes (FW=OFF +
MaxUnflushed* set up) is that pages are written into the file system
cache (and it doesn't not guarantee any disk writes) and then
Dmitry Yemanov [2011-10-25 17:55] :
> 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 cr
On Tue, Oct 25, 2011 at 08:03:39AM -0200, Adriano dos Santos Fernandes wrote:
> Let consider ext3/4 filesystem with barriers enabled, then:
...
> 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
No. Barrier is someth
On Tue, Oct 25, 2011 at 10:01:37PM +0100, james wrote:
> >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
On 10/26/11 14:26, Lester Caine wrote:
> Paul Reeves wrote:
>> Everything really depends on the manufactures claims that the capacitors can
>> flush the cache successfully. Can we trust them?
> It's not just the drives capacity that matters here. Most of the machines
> I've
> checked will contin
Paul Reeves wrote:
> Everything really depends on the manufactures claims that the capacitors can
> flush the cache successfully. Can we trust them?
It's not just the drives capacity that matters here. Most of the machines I've
checked will continue to run for several seconds after mains is remov
Dimitry Sibiryakov wrote:
> 26.10.2011 11:05, Ted Miglautsch wrote:
>> The problem with using the energy from rotating to write data is as you
>> remove the energy the rotation slows so it is not possible to write as
>> the disk slows down.
>
>It is hard, but I don't see a technical problem in
26.10.2011 11:05, Ted Miglautsch wrote:
> The problem with using the energy from rotating to write data is as you
> remove the energy the rotation slows so it is not possible to write as
> the disk slows down.
It is hard, but I don't see a technical problem in synchronizing write
frequency wit
Dimitry Sibiryakov wrote:
> 26.10.2011 8:58, Alex Peshkoff wrote:
>> Probably I've missed some details. Capacitor present on HDD is really
>> enough only for making sector's writes atomic. A solution with capacitor
>> to save cache somewhere requires additional flash RAM - in that case not
>> too b
On Wednesday 26 October 2011 at 10:14 Dimitry Sibiryakov wrote:
>Don't forget about the energy from rotating. In old HDD it was enough
> for heads' parking. In modern models it may be enough for cache writing as
> well.
I think that 'may be enough' is the problem. We just don't know. And it
26.10.2011 8:58, Alex Peshkoff wrote:
> Probably I've missed some details. Capacitor present on HDD is really
> enough only for making sector's writes atomic. A solution with capacitor
> to save cache somewhere requires additional flash RAM - in that case not
> too big capacitor is enough to save w
On 10/26/11 01:01, james wrote:
> Alex:
>
> > Provided that HDD has no capacitor enough to flash cache in case of
> > power failure. As far as I know they typically have.
>
> That's news to me. What evidence do you have? Given the large size of
> on-disk buffers these days, it would need to b
>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
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/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
40 matches
Mail list logo
