[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference ssag::ask_ssag

Title:Ask the Storage Architecture Group
Notice:Check out our web page at http://www-starch.shr.dec.com
Moderator:SSAG::TERZAN
Created:Wed Oct 15 1986
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6756
Total number of notes:25276

6739.0. "Dynamic extension of RAID 5 set?" by CGOOA::OWONG (SKIWI in Canada (VAO)) Mon Jun 02 1997 14:09

    One of my customers has indicated to me that IBM amd Mylex both now
    have RAID 5 controllers whereby you can dynamically extend the size of
    the hardware RAID 5 set by adding in another disk drive.
    
    My understanding of RAID 5 was that you would need a backup/restore
    cycle to increase the size of the hardware raidset.
    
    Could someone give me and idea how the IBM and/or Mylex controllers
    would work and do we have plans for similar capability with our RAID
    controllers?
    
    	Owen.
T.RTitleUserPersonal
Name
DateLines
6739.1Dynamic degredationNQOS01::nqsrv445.nqo.dec.com::smith_pMon Jun 02 1997 15:0112
To my knowledge the only major players in RAID that have shipped a product 
with "dynamic" disk growth within RAID 5 is HP (Autoraid) and Storage 
Dimensions.  

Both of these companies have had limited success with these products due 
to the RAIDSET size limitations and the major performance degredation as 
drives are added.

If IBM and Mylex are adding this function to their controllers they will 
experience the same issues.

Paul
6739.2EPS::VANDENHEUVELHeinMon Jun 02 1997 22:5245
 >   Could someone give me and idea how the IBM and/or Mylex controllers
 >   would work and do we have plans for similar capability with our RAID
    
    The basic algoritme would not be too dificult from the disk angle. 
    I suspect the bigger challenge is to make it work from a filesystem
    perspective. Ever thought through how to tell a VMS ODS-2 disk that 
    it got bigger all-of-the-sudden? It has a storage bitmap in the which
    would have to grow and gory details like that! Also, making it fail-
    safe and/or allowing online access adds some chalenge. 
    
    Let's say you have a 4 member raid-5 and add a fifth member.  I'd think
    it'd go liek this: You'd read a long stripe from each disk. So for the
    first disk read block 4,7,P,13,... for the second 5,P,10,14,...
    Now shuffle all down a block, writing 4 where 1+2+3 Parity was,
    5 where 4 was,... At first you can only safely write a block at
    a time. But after 4 rows you've created a 2 block gap that can be
    filled in a single write safely. After a short while you are reading
    well ahead of the writing (N+1/N) and can read and write out decend
    sized chunks for reasonable performance. You could pre-write the new 
    member with a pattern (zeroes, ones, whatever) to recognize how for 
    you got in case of a bad failure (boot). Actually, thinking about it,
    I'd probably code the move for the first 128*N blocks as single block
    moves, and then kick in a 64KB reconstruct algoritme.
    
    
    O1   O2   O3   O4		N1  N2  N3  N4   N5
    
    1    2    3    123		1   2   3   4    1234
    4    5    456  6		5   6   7   5678 8
    7    789  8    9            9   10  P   11   12
    P    10   11   12           13  P   14  15   16
    13   14   15   P            P  17   18  19   20
    16   17   P    18
    
    You'd have to have a multi fence-post mechanisme in place to deal 
    with online access if that is acceptable: From the new set, from 
    the old set, in the buffers. As I wrote in the opening, the harder
    tasks is probably to get teh OS buy in to reconfigure the On Disk
    Structure (Be it ODS-2, NTFS, AdvFS, UFS, FAT or what have you 
    not) on the fly to accomodate the new size. It is not obvious to
    me how storageworks and/or mylex could help there.
    
    Just rambling,
    			Hein.
                                             
6739.3Merely ballistic missle science vs. rocket science.SSDEVO::ROLLOWDr. File System's Home for Wayward Inodes.Tue Jun 03 1997 00:3412
	For UFS it is surprisingly simple, though how much space
	you can add may be constrained.  UFS is organized as
	groups of "cylinders" (whatever that may happen to be).
	To grow a file system you simply tack on new cylinder
	groups.  Filling out the last cylinder group may take a
	bit of work, but the per-group bit map for it had the
	any non-existant space marked as "full".

	IBM figured this about over five years ago.  Most other
	UNIX vendors offer something to extend their FFS based
	file systems.  We removed the utility that OSF included 
	in their distribution to do it.
6739.4We got one now.PCBUOA::WHITECParrot_TrooperWed Jun 04 1997 15:2014
    check out the PCBU Server Engineering support page.
        
        akin40.ako.dec.com 
    
    	WHAT'S HOT!   .......MORE  Mylex Online Raid Expansion.....
    is the technology, and the PCBU Has it now!
        
        It requires a minimum revision Rev E Mylex controller FR_PCTAR-EA, EB,
        EC for one two or three channel at a minumum of firmware.......hey,
        look at the web page it's all there.  There will be a techtip posted 
        by the weekend.  The required firmware and drivers are there too.
        
        chet
    
6739.5so what value do we add?TROOA::MSCHNEIDER[email protected]Wed Jun 04 1997 21:124
    Yes how come our generic PCBU Mylex controllers have this feature and our
    "value-added" StorageWorks Mylex controllers don't.  Other peeves are the
    lack of support for Mylex's Global Access Manager software on our
    variant.