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]


Date:

om>
From: =?ISO-8859-1?Q?Bj=F8rn_Vermo?= <bv@opera.com>
Subject: Re: RAID 1 or Hammer
Date: Wed, 14 Jan 2009 14:05:46 +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 v930.3)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
References: <496b8121$0$881$415eb37d@crater_reader.dragonflybsd.org> <496b961e$0$882$415eb37d@crater_reader.dragonflybsd.org> <882FE201-9FFB-40B7-A945-DD21337DD661@freemail.gr> <496BC215.80805@fs.ei.tum.de> <3a7f57190901121726q69357919k52ece0b1775fdd11@mail.gmail.com> <200901130315.n0D3FlP9038935@apollo.backplane.com> <E663E77A-8DA0-4294-88E5-961385920B4D@opera.com> <496DA32B.8050803@fs.ei.tum.de> <EC89B64F-B8C1-498A-8489-4258865E1CB4@opera.com> <6D9E2264-1DAD-4B23-A03F-0636D24C363E@yberwaffe.c
om>
In-Reply-To: <6D9E2264-1DAD-4B23-A03F-0636D24C363E@yberwaffe.com>
Sender: users-errors@crater.dragonflybsd.org
Errors-To: users-errors@crater.dragonflybsd.org
Lines: 53
NNTP-Posting-Host: 216.240.41.25
X-Trace: 1231938643 crater_reader.dragonflybsd.org 883 216.240.41.25
Xref: crater_reader.dragonflybsd.org dragonfly.users:11896


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 ought =20=

>> to have the addresses inverted, so sector 1 on one drive is mapped =20=

>> to sector MAX -1 on the other.
>
> I read it like the locality (radius) of the errors occur on the same =20=

> disc,
> so I don't see the benefit from your "reversed mirror strategy".

He clearly stated that some drives models had error spikes at certain =20=

cluster numbers.
This should not really surprise anybody who is familiar with the way =20
modern drives work internally. The cylinder where you change to a =20
different data density is a border case, and any border cases open =20
extra bug opportunities.

>
>
> 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 outer =20=

> tracks.


A smart controller could make that into an opportunity. It is hardly =20
any more difficult than staggered stripes, which is widely implemented.

In most mirroring controllers I have seen the system will get the read =20=

data from the first drive that has them ready. Two "opposite" drives =20
should be able to offer a better average read performance.

--=20
Bj=F8rn Vermo
Core networking
Opera Software ASA








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