No subject

Unknown Unknown
Wed Jan 14 05:59:34 PST 2009

om> <0E59E23F-6F9E-496A-9F38-2B49C527B815 at>
From: Jasse Jansson <jasse at>
Subject: Re: RAID 1 or Hammer
Date: Wed, 14 Jan 2009 14:52:51 +0100
List-Post: <mailto:users at>
List-Subscribe: <mailto:users-request at>
List-Unsubscribe: <mailto:users-request at>
List-Help: <mailto:users-request at>
List-Owner: <mailto:owner-users at>
MIME-Version: 1.0 (Apple Message framework v753.1)
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <0E59E23F-6F9E-496A-9F38-2B49C527B815 at>
Sender: users-errors at
Errors-To: users-errors at
Lines: 63
X-Trace: 1231941709 883
Xref: dragonfly.users:11897

On Jan 14, 2009, at 2:05 PM, Bj=F8rn Vermo wrote:

> On 14. jan.. 2009, at 12.17, Jasse Jansson wrote:
>> First of all, thanks Simon for the links, It sure was interesting =20
>> reading.
>> On Jan 14, 2009, at 11:45 AM, Bj=F8rn Vermo wrote:
>>> I have toyed with the idea that one drive in a mirrored pair =20
>>> ought to have the addresses inverted, so sector 1 on one drive is =20=

>>> mapped to sector MAX -1 on the other.
>> I read it like the locality (radius) of the errors occur on the =20
>> same disc,
>> so I don't see the benefit from your "reversed mirror strategy".
> He clearly stated that some drives models had error spikes at =20
> certain cluster numbers.
> This should not really surprise anybody who is familiar with the =20
> way modern drives work internally. The cylinder where you change to =20=

> a different data density is a border case, and any border cases =20
> open extra bug opportunities.

That's true.

>> You will also get some interesting performance problems to tackle, =20=

>> when
>> one disc works on the inner tracks and the other one is on the =20
>> outer tracks.
> A smart controller could make that into an opportunity. It is =20
> hardly any more difficult than staggered stripes, which is widely =20
> implemented.
> In most mirroring controllers I have seen the system will get the =20
> read data from the first drive that has them ready. Two "opposite" =20
> drives should be able to offer a better average read performance.

Sure, reads is no problem.
I was thinking about write performance and possible sync windows,
but I didn't spell it out. My bad.

Kaiser Jasse -- Authorized Stealth Oracle

The axioms of wisdom:
1. Go the SPARC way of life
2. You can't conquer the universe without the knowledge of FORTRAN
3. In the Unix realm, 10% of work fixes 90% of the problems

More information about the Users mailing list