Date: Wed, 11 May 2005 09:03:43 -0500 (CDT) From: Tony Shadwick <tshadwick@goinet.com> To: Subhro <subhro.kar@gmail.com> Cc: freebsd-questions@freebsd.org Subject: Re: Hardware RAID 5 - Need vinum? Message-ID: <20050511085916.O15987@mail.goinet.com> In-Reply-To: <42817BEC.5060901@gmail.com> References: <20050510155942.V34838@mail.goinet.com> <42817BEC.5060901@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050511085916.O15987>