DragonFly users List (threaded) for 2009-01
DragonFly BSD
DragonFly users List (threaded) for 2009-01
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

[no subject]


om> <0E59E23F-6F9E-496A-9F38-2B49C527B815@opera.com>
From: Jasse Jansson <jasse@yberwaffe.com>
Subject: Re: RAID 1 or Hammer
Date: Wed, 14 Jan 2009 14:52:51 +0100
BestServHost: crater.dragonflybsd.org
List-Post: <mailto:users@crater.dragonflybsd.org>
List-Subscribe: <mailto:users-request@crater.dragonflybsd.org?body=subscribe>
List-Unsubscribe: <mailto:users-request@crater.dragonflybsd.org?body=unsubscribe>
List-Help: <mailto:users-request@crater.dragonflybsd.org?body=help>
List-Owner: <mailto:owner-users@crater.dragonflybsd.org>
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@opera.com>
Sender: users-errors@crater.dragonflybsd.org
Errors-To: users-errors@crater.dragonflybsd.org
Lines: 63
X-Trace: 1231941709 crater_reader.dragonflybsd.org 883
Xref: crater_reader.dragonflybsd.org 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

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]