• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Incrementally Building a RAID?

M

Monaro

n00b
Joined
Jun 7, 2007
Messages
13
I've purchased a PERC 6 and have only just made myself aware of some of the idiosyncrasies of building a RAID 6 - specifically the type of drives to use. So I thought it prudent I go over budget and get the most suitable drives (Hitachi 7K2000 seems to be the most recommended) instead of reusing my Seagate 1TB drives.

But in going over budget, I can't afford to drop the cash for 8 of these puppies all at once. Is there any technical drawback of building an array over a period of time? Start with 4 and just buy another each month? Will it impact performance down the line – incrementally adding new disks? I guess I’m asking from a fragmentation and/or stripe point of view, and whether I'd have to set it up any differently than starting with a full compliment of disks.

Relevant info:
Purpose: Media server (large files, very few rewrites)
Environment: Windows Server 2008 R2 NTFS

Thanks in adnvance.
 
That sounds like a good application for FlexRAID or UnRAID. Whenever you add a disk, all you need to recalculate is the parity. Also, you can add different size drives to the array and all space will be utilized, as long as your parity drive(s) are at least as large as the rest of the drives in the array.

But if you use conventional distributed parity RAID, then whenever you add a disk, the entire array must be rebuilt in a process called "online capacity expansion". I'm not familiar with the PERC RAID card, so someone else can chime in with OCE experiences. But it is generally a very slow process.
 
Last edited:
HelioX said:
ZFS does this very well.
Click to expand...

No, that is incorrect.

ZFS cannot expand a RAID pool. It can only add additional pools. So, for example, you could add 4 more disks as an additional RAID 5 pool, and pool that with an existing RAID 5 pool.

But you cannot expand a raidz or raidz2 one disk at a time, like it sounds the OP wants to do.
 
After your reply John I did a bit of a search for OCE and expanding RAID 6 from within the PERC 6 and it seems to be possible - Amazing what you can find once you know the terms to search for :)

I expected it would be a slow process, as it has to rewrite/redistribute data across a larger array - does this have any negative effect though? Continually expanding an array? I guess if its only fragmentation that can be fixed, right?
 
@Monaro: Leveraging OCE by adding 1 or 2 drives at a time to take advantage of falling harddisk costs over time is something a lot of people are doing, and totally feasible with a current gen hardware raid card. And no, there is performance penalty "down the line" as a side effect of OCE. Reaching the point of 8-drives in an array by adding 1 drive at a time will be the same performance as starting with 8.

As an alternative to a hardware raid card though you could consider FlexRaid and a cheaper non-RAID host card.

@john4200: you're right, but you forgot to mention that every time you add additional drives in raidz or raidz2 to an existing pool, you're losing another parity drive, so "adding as you go" really blows with ZFS. it's essentially just stringing multiple arrays together rather than expanding a single one. that was a dealbreaker for me, and you don't hear ZFS cheerleaders talk about it much. there are plenty of things to like about ZFS though, for example when you replace a drive and "resilver" the pool, it only deals with blocks that are actually in use by the filesystem, rather than recomputing parity for every single block of the drive like a hardware array controller. hopefully hardware array controllers will eventually evolve to having file system awareness, so they too would be able to deal with only blocks actually in use, and be able to do things like support TRIM on SSD drives.
 
Last edited:
odditory said:
hopefully hardware array controllers will eventually evolve to having file system awareness, so they too would be able to deal with only blocks actually in use, and be able to do things like support TRIM on SSD drives.
Click to expand...

:eek: Now that would be nice, but can you imagine how many file systems they'd have to be aware of? NTFS, ext4, UFS, HFS and its variants, JFS, XFS, btrfs...
 
From what I understand the inability to add drives to a zpool and just grow it has something to do with some "pointer" crap, same reason why you can't go from dedupe to undeduped for the entire data that's already written (you can switch a zpool though on the fly, it's just applied to data in the future)
 
ZFS seems to invade every single thread here. You lot should at least try to help instead of just pitching it at every single opportunity available. To answer the question however, yes, you can expand the array quite easily. Performance will not go down, only up as you add more drives, except for when the actual expansion is occurring. No real drawbacks to it except for the fact that you have to rebuild the array, performance will be lower and you will have to wait for the expansion to finish if you have a drive failure before you can rebuild, but that's about it.
 
Appreciate all the answers guys. Thanks a lot.

Card is almost here. Will scrouge around for a bracket, and might just get all the drives at once (have enough data to fill the 11TB).

And skip meals for a few weeks :)
 
You must log in or register to reply here.
Back
Top