Re: [GENERAL] Arguments Pro/Contra Software Raid - Mailing list pgsql-performance

From Markus Schaber
Subject Re: [GENERAL] Arguments Pro/Contra Software Raid
Date
Msg-id 4461FF69.4080209@logix-tt.com
Whole thread Raw
In response to Re: [GENERAL] Arguments Pro/Contra Software Raid  (Markus Schaber <schabi@logix-tt.com>)
List pgsql-performance
Hi, Bruce,

Markus Schaber wrote:

>>>It does not find as much liers as the script above, but it is less
>>Why does it find fewer liers?
>
> It won't find liers that have a small "lie-queue-length" so their
> internal buffers get full so they have to block. After a small burst at
> start which usually hides in other latencies, they don't get more
> throughput than spindle turns.

I just reread my mail, and must admit that I would not understand what I
wrote above, so I'll explain a little more:

My test programs writes byte-for-byte. Let's say our FS/OS has 4k page-
and blocksize, that means 4096 writes that all write the same disk blocks.

Intelligent liers will see that the the 2nd and all further writes
obsolete the former writes who still reside in the internal cache, and
drop those former writes from cache, effectively going up to 4k
writes/spindle turn.

Dumb liers will keep the obsolete writes in the write cache / queue, and
so won't be caught by my program. (Note that I have no proof that such
disks actually exist, but I have enough experience with hardware that I
won't be surprised.)


HTH,
Markus

--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org

pgsql-performance by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: [HACKERS] Big IN() clauses etc : feature proposal
Next
From: Markus Schaber
Date:
Subject: Re: [HACKERS] Big IN() clauses etc : feature proposal