Message-ID: <4461FF69.4080209@logix-tt.com>
Date: Wed, 10 May 2006 16:57:45 +0200
From: Markus Schaber <schabi@logix-tt.com>
Organization: Logical Tracking and Tracing International AG, Switzerland
User-Agent: Debian Thunderbird 1.0.7 (X11/20051017)
MIME-Version: 1.0
To: PostgreSQL General <pgsql-general@postgresql.org>
Cc: "Pgsql-Performance ((E-mail))" <pgsql-performance@postgresql.org>
Subject: Re: [PERFORM] Arguments Pro/Contra Software Raid
References: <200605101401.k4AE1XQ08859@candle.pha.pa.us>
	<4461FAD9.6020106@logix-tt.com>
In-Reply-To: <4461FAD9.6020106@logix-tt.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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