Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 31 Jan 2000 16:27:31 +1030
From:      Greg Lehey <grog@lemis.com>
To:        Tom <tom@sdf.com>
Cc:        Marc Tardif <admin@wtbwts.com>, freebsd-scsi@FreeBSD.ORG
Subject:   Re: hardware vs software stripping
Message-ID:  <20000131162728.C68925@freebie.lemis.com>
In-Reply-To: <Pine.BSF.4.05.10001302130260.5637-100000@misery.sdf.com>
References:  <20000131155356.B68925@freebie.lemis.com> <Pine.BSF.4.05.10001302130260.5637-100000@misery.sdf.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday, 30 January 2000 at 21:37:06 -0800, Tom wrote:
>
>>>   Second, a DPT can't do RAID 5 + 0.  It does the RAID 5 in
>>> hardware.  The RAID 5 you'll have to do in software.
>                    RAID 0
>>
>> Hmm.  There's obviously a typo here, but I'm not sure how to correct
>> it.  I don't know the DPT implementation, but in Vinum RAID-5 implies
>> striping.  I'd be interested in hearing how DPT does it.
>
>   RAID 5 on the DPT.  RAID 0 in software. 

You misunderstand.  RAID-5 in Vinum is implemented as a variant of
RAID-0.  Check http://www.lemis.com/vinum.html for details.

> Create two or more RAID 5 volumes on the DPT, then strip all DPT
> volumes into one big software volume using ccd (a lot of this
> predates vinum).  The RAID 0 can help insuluate you from the
> generally crummy write performance of RAID 5.

Not much.

>>>   An Infortrend (see below) can do a transparent copy-and-replace array
>>> expansion.  This however just leaves you with a bigger virtual disk.
>>> FreeBSD has no way to grow a filesystem transparently.  You can disklabel
>>> the addtional space and make a new filesystem though.
>>
>> In a similar way, you can increase the size of a concatenated Vinum
>> plex, or add another, larger plex to a volume.  Both would increase
>> the size of a volume.  Some people also have tools for increasing the
>> size of a ufs file system, but they still need work.
>
>   These tools are also strictly off-line too.  Solaris' growfs is very
> disapointing in that all process that write just block until growfs is
> completed.  Depending on your application, that may be unacceptable.

I can understand the problem.  I don't think we'll get any better than
that either.

Greg
--
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000131162728.C68925>