From owner-freebsd-questions@FreeBSD.ORG Wed May 11 14:03:45 2005 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A35816A4CE for ; Wed, 11 May 2005 14:03:45 +0000 (GMT) Received: from mail.goinet.com (mail.goinet.com [208.207.72.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D2E943D75 for ; Wed, 11 May 2005 14:03:45 +0000 (GMT) (envelope-from tshadwick@goinet.com) Received: from mail.goinet.com (localhost.goinet.com [127.0.0.1]) by mail.goinet.com (8.13.1/8.13.1) with ESMTP id j4BE3hY4085155; Wed, 11 May 2005 09:03:43 -0500 (CDT) (envelope-from tshadwick@goinet.com) Received: from localhost (tshadwick@localhost)j4BE3hIi085151; Wed, 11 May 2005 09:03:43 -0500 (CDT) (envelope-from tshadwick@goinet.com) X-Authentication-Warning: mail.goinet.com: tshadwick owned process doing -bs Date: Wed, 11 May 2005 09:03:43 -0500 (CDT) From: Tony Shadwick To: Subhro In-Reply-To: <42817BEC.5060901@gmail.com> Message-ID: <20050511085916.O15987@mail.goinet.com> References: <20050510155942.V34838@mail.goinet.com> <42817BEC.5060901@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on mail.goinet.com X-Virus-Status: Clean cc: freebsd-questions@freebsd.org Subject: Re: Hardware RAID 5 - Need vinum? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2005 14:03:45 -0000 The problem I've had in the past in Windows for example: Drive D: is a RAID5 volume, 400GB, nearly full. If I add a 200GB drive to the array, the 'disk' that Drive D: resides on is now ~600GB, but Drive D: will remain 400GB. I would have to utilize a third party piece of software to resize Drive D: to utilize all 400GB, or create another partition to use that extra 200GB. In my case. /media/video will still only have 400GB available to it. I'm creating one partition on the array with one slice. My understanding then is if I go into the label editor after adding my new drive, I'll have 200GB of free space, and I could create another slice and another mountpoint, but not simply add that additional space to my original slice and mountpoint at /media/video. Now, since I originally posted this message, I did more digging, and found some posts regarding growfs. Perhaps that command is what I'm looking for, and would allow me to grow /media/video to use all 600GB in that case. Now my only concern is whether or not the SX6000 support nondestructively growing a RAID5 array. If I'm right about growfs that is. :) On Wed, 11 May 2005, Subhro wrote: > On 5/11/2005 2:35, Tony Shadwick wrote: > >> What my concern is when I start to fill up the ~400GB of space I'm giving >> myself with this set. I would like to simply insert another 200GB drive >> and expand the array, allowing the hardware raid to do the work. > > That is what everybody does. It is very much normal. > >> >> The problem I see with this is that yes, the /dev/(raid driver name)0 will >> now be that much larger, however the original partition size and the >> subsequent slices will still be the original size. > > I could not understand what you meant by RAID device entry would be larger. > The various entries inside the /dev are nothing but sort of handles to the > various devices present in the system. If you want to manipulate or utilize > some device for a particular device present on your box from a particular > application, then you can reference the same using the handles in the /dev. > And the handles remains the same in size irrespective of whether you have 1 > hard disk or 100 hard disks in some kind of RAID. > >> Do I need to (and is there a way?) to utilize vinum and still allow the >> hardware raid controller to do the raid5 gruntwork and still have the >> ability to arbitrarily grow the volume as needed? The only other solution >> I see is to use vinum to software-raid the set of drives, leaving it as a >> glorified ATA controller card, and the cpu/ram of the card unitilized and >> burden the system CPU and RAM with the task. > > The main idea in favor of using Hardware RAID solutions over software RAID > solutions is you can let the CPU do things which are more worthwhile than > managing I/O. The I/O can be well handled and is indeed better handled by the > chip on the RAID controller card than the CPU. If you add another disk to > your RAID or replace a dead disk at any point of time, then the RAID card > should automatically detect the change and rebuild the volumes as and when > required. This would be completely transparent to the OS and sometimes also > transparent to the user. > > Regards > S. >