The Pegasus is pretty good, but it's not perfect. Every so often - infrequently, the nMP will go to sleep but the P2 stays awake. Wups! If you wake the computer you have to reboot because the computer will hang trying to access it. I forget if I cycle power before waking the computer if it works, or what exactly. But its an annoying issue that shouldn't be happening.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Is the PROMISE Pegasus2 for me.
- Thread starter puckhead193
- Start date
- Sort by reaction score
I'm sure it could be, but it's unlikely for a multitude of reasons. It just doesn't make sense to do that. You want to have only one source of truth and having it on the disks makes the most sense.
If you pull the disks and replace them with new disks then the NVRAM config is going to be invalid.
If you insert a set of old disks from the same controller which were configured with a different RAID level then the NVRAM config is going to be invalid.
If you pull the disks and re-insert them in a different order then the NVRAM config is going to be invalid.
Conflicting configs and an unintentional, automated battle over which is correct is the last thing you want and just adds complexity and additional risk of data loss where it's not needed, IMO.
From SOHO RAID all the way up to enterprise, the vast majority of storage systems store the metadata on the disks and have nothing related to the RAID config stored on the controller.
Citation?
The most popular servers have NVRAM on their RAID controllers. If you have non-volatile writeback cache, it's pretty much imperative to keep metadata on the controller.
Real-world experience. NetApp and EMC are excellent examples of this.
http://www.emc.com/collateral/hardware/white-papers/h11181-data-integrity-wp.pdf
NetApp's NVRAM is there for the same reason, though due to how NetApp's WAFL works the process for writing the data to disks is a bit different.
You are misunderstanding the purpose of NVRAM used for write cache, such as what NetApp uses in their filers and EMC uses in their appliances. This NVRAM does not store the RAID configuration information, it stores non-committed writes. In the event of a fault that causes a non-clustered head (controller) to crash, the non-committed writes are held in NVRAM until the head boots back up. Before the boot sequence completes it checks for any pending write logs in NVRAM that haven't been committed and will replay the logs, writing that pending data to disk. NVRAM on a non-clustered filer is split 50/50, using half to commit writes when full (or when a CP is triggered) while the other half caches new writes.
On a clustered filer the NVRAM is split 50/50, half is for writes to its own disk groups and half to mirror the partner's NVRAM. Should the partner crash with pending writes then the surviving head takes over for the partner, brings its disk groups online, and then commits the pending writes on behalf of the down head.
At no point does the NVRAM contain the disk group, aggregate, or volume configuration information. This is all stored on the disks.
Same goes for Areca RAIDs, sounds like the Pegasus units are the same as well.
Same goes for EMC CLARiiON, VNX, etc. The NVRAM is used for writes in the event of failure or power loss, not for RAID/disk configuration.
You can physically move entire volume groups from one controller to another without having to tell the controller anything because the metadata is stored on the disks.
Just to be contrary, I will point out that HP's SmartArray controllers* store the RAID configuration in the controller as well as on the drives.
A.
* at least all the ones that I have touched.
Yes, however that is a slightly different product.
Dell PERC do the same and, unfortunately, it has been a problem that some people have run into. Goes back to not having a single source of truth and conflicts that can potentially result in data loss.http://en.community.dell.com/support-forums/storage/f/1216/t/19454109.aspx
I'm not aware of any stand-alone appliances that rely on NVRAM for RAID configuration. There may be some out there somewhere, but I have not come across any.
What place in that long document do you think supports your theory?
My EMC arrays not only store metadata, but there's a 5 disk RAID-5 LUN reserved for long-term retention of cache contents and metadata - and a built-in UPS with enough runtime to copy all of the cache and metadata to that RAID-5 LUN
And, if someone has swapped the disks, those sectors will be written to the wrong drive - unless the controller maintains non-volatile metadata about the drives to detect that drive movement has occurred. It cannot be stored on the drives, since a sudden interruption of power prevents updating metadata on the drives.
Exactly my reference to "The most popular servers have NVRAM on their RAID controllers".
That's a big change from "From SOHO RAID all the way up to enterprise, the vast majority of storage systems store the metadata on the disks and have nothing related to the RAID config stored on the controller".
And "rely" is different from what I'm talking about, where the controller stores metadata in controller NVRAM as well as on disk, and compares the two to do the right thing when the configuration changes.
The HP SMART controllers seem to typically stop during boot and ask the admin what to do - although if you have a redundant array with a missing member they will grab any unknown disk to rebuild the array. (Even if that was a disk that had good data that you wanted to access.)
For HP, they're doing the right thing for customers who have highly paid system admins in central offices (like me), who need to tell minimum-wage datacenter droids to "get a 900 GB HP SAS hotplug drive and replace the drive in Bay 19, Rack 8, RU 23 that has the blue light on". (Yes, from my office in Mountain View I can turn on a blue LED on a disk drive in Singapore to help ensure that the droid pulls the right drive.)
Last edited:
It's not a theory, check out page 16.
I can understand having a way to write cache to disk for "long term" storage in the event of a natural disaster where the power could be out for longer than the UPS or other back-up power can run. I don't see the point in having a backup of the metadata, if the metadata on a disk is lost due to failure then I wouldn't trust the data on the disk to not be corrupt or lost as well, not only that the checksums would likely be invalid/incorrect and a parity check and rebuild would need to be done for that disk group and the disk itself rebuilt. In the event of multiple disk failures within a group, well...your data is lost anyway and the metadata isn't going to get it back.
Uhhhhh, the whole point of the metadata is to tell the controller what part of the group it belongs to. It has nothing to do with physical location. I can shut my arrays down, move the disks around, and bring it back up without a problem. There is ZERO chance of data being written to the wrong disk. What is this, I don't even...
Perhaps you're misunderstanding what metadata is based on your second sentence?
You definitely seem to be confused, though.We are talking about stand-alone storage appliances, not server RAID controllers. Two very different animals and design specs. Do they both do RAID? Yes. You can't compare HP SmartArray or Dell PERC RAID controllers to EMC or NetApp appliances.
Only because you're comparing apples to oranges, this discussion has been about storage systems, as in stand-alone arrays/appliances and not integrated components. Not server storage subsystems.
Again, you're talking about completely different products in order to support your argument. Stay on topic, which is external storage arrays. Not to mention I've referenced at least one instance where having configuration data stored in two places has resulted in a conflict that required physical human intervention to resolve.
They will not grab a disk unless it's marked as a hot spare and if you mark a currently-unused disk with data on it as a hot spare then that mistake is on you. A controller that would grab any "unknown" disk and use it as a spare would be an epic fail. We're talking massively epic. I'm not sure where you're getting these ideas from.
Perhaps someday you can be an even better admin and implement an automated system, like ours, that automatically alerts SiteOps to drive and other hardware failures. However, you're talking about servers again and driving off-topic.
It seems you have a misguided idea of what metadata is, what it's for and how storage arrays make use of it. You do know that metadata isn't sent from client hosts to the array as part of write operations, right?
And again, we're talking about storage arrays and appliances here, not server RAID.
Page 16 says:
To me, that says that there is meta-data saved in NVRAM in the controller.
As a real experiment, I powered down an unused EMC array, disconnected all the storage shelves, and powered it back up. When I looked at the array, I saw the attached image.
Clearly, there must be some non-volatile meta-data stored in the controller for it to be able to tell me which arrays and disks were missing!
Attachments
Thank you for confirming that you are confused/not understanding what disk metadata is. Tracking the consistency using parity is NOT disk metadata.
Here's an example of "disk metadata" using a non-technical scenario.
You have a classroom (appliance) with a teacher (the controller) and students (the disks) which sit at desks (bays in the chassis). Everyone comes in and sits down, the teacher passes out an exam to all the students, they fill it out with their name and answer the questions, then turn it back in.
The next day everyone comes in and sits down, however the students have chosen to sit at different desks. The teacher has graded the exams and is returning them to the students. The teacher isn't going to return the exams to the same desks they were picked up from, right? That would end up giving the exam back to the wrong students. So how does the teacher know who gets which exam? Metadata.
Each student has unique identifiers; Their name and their face. The exams are tagged with an identifier, so the teacher is able to easily return the exams to the correct students.
The same goes with disk metadata. This metadata tells the controller about the disk, what group it belongs to, what its role is, etc. That is what disk metadata is. Disk metadata is not the RAID parity/conistency info. Disk metadata is not what the clients send to the controller to be written to the disks.
Admittedly I'm not as familiar with EMC as I am with NetApp since we have far fewer EMC arrays than NetApp, after doing some more checking you are correct for pre-VNX2 gear. My apologies.
EMC VNX2 and the new flare code change this behavior. NetApp stores the metadata on the drives and stores nothing on the controller so you could play the shell game with shelves/drives and everything would still come back up without issue. Areca and Pegasus RAID enclosures do the same.
In any case, this discussion is so last week that I have no idea why we're still going down this road. Perhaps we can shake hands and concede that we're both right as it really depends on the generation/model of hardware and isn't something that's specific to a given vendor.
In any case, we're way off topic here and this hasn't really helped the OP with their decision any. The bottom line is that the Pegasus boxes store the disk metadata on the disks in order to prevent data loss in the event of a controller failure; You can replace the controller and get back online without issue since it reads that info off the disks.
I agree with one thing....
I agree 100%.
But I consider everything else to be metadata (data about data), be it config info, cache tags, or anything else that the controller stores to manage the client data.
The safest thing to do is to keep config metadata both on the disk and in controller NVRAM. That way you know if disks are missing (as in the EMC example), and can warn the admin if disks move - since that's not a typical thing.
It also makes it possible for the controller to recognize that an unknown volume has been inserted (such as when you move the Pegasus disks to new Pegasus) and ask for confirmation before using the drives. (For example, some RAID systems will recognize the new volume, but require you to "import" the drives before they will be used.)
I agree 100%.
But I consider everything else to be metadata (data about data), be it config info, cache tags, or anything else that the controller stores to manage the client data.
The safest thing to do is to keep config metadata both on the disk and in controller NVRAM. That way you know if disks are missing (as in the EMC example), and can warn the admin if disks move - since that's not a typical thing.
It also makes it possible for the controller to recognize that an unknown volume has been inserted (such as when you move the Pegasus disks to new Pegasus) and ask for confirmation before using the drives. (For example, some RAID systems will recognize the new volume, but require you to "import" the drives before they will be used.)
So my R4 came today. I initialized it. I'm trying to figure out how to i guess reformat it and make it a RAID 0.
This is all done via the Promise Utility. (Re)configuring the RAID starts on page 59 of the manual - http://www.promise.com/media_bank/Download Bank/Manual/Pegasus2_Product Manual.pdf
Let us know what you think!
What about under the "Disk Array" or "Logical Drive" sections, do you see a way to remove the existing Array/Drive so you just have 4 unused/uninitialized drives? Once you get to that state then you should be able to go through the setup.
Odd that the utility doesn't have the option to let you delete the existing config and create a new one. I assume the options are greyed out because there are no free disks left to configure.
This is what is in the disk array. What is odd is that I have 0 bytes free
Nothing is on the drive.
Attachments
This is what is in the disk array. What is odd is that I have 0 bytes free
Nothing is on the drive.
And under Logical Drive you have...? That screen tells me there is 1 logical drive created, that is where you need to go next. I don't know what the R4 comes configured as by default (RAID5? RAID0?) but the Logical Drive section of the utility should tell you that. If it's RAID5 and you want RAID0 then you should be able to delete the existing logical drive and create a new RAID0 logical drive.
Flying by the seat of my pants here since I haven't actually used the Pegasus stuff before.
And under Logical Drive you have...? That screen tells me there is 1 logical drive created, that is where you need to go next. I don't know what the R4 comes configured as by default (RAID5? RAID0?) but the Logical Drive section of the utility should tell you that. If it's RAID5 and you want RAID0 then you should be able to delete the existing logical drive and create a new RAID0 logical drive.
Flying by the seat of my pants here since I haven't actually used the Pegasus stuff before.
Here's a screenshot of the logical drive tab. I'm scared to change any thing. Most of the time I have someone at work do it
Appreciate your help!
Attachments
Here's a screenshot of the logical drive tab. I'm scared to change any thing. Most of the time I have someone at work do it
Appreciate your help!
Well, since you have no data on there yet there's nothing to be afraid of.
So you have a RAID5 logical drive using the entire disk array (That is why the disk array screen says 0 free). In the Logical Drive screen you would click "Delete" to remove the RAID5 logical drive, then the button below "Background Activities" should be available. Click that and you should be able to go through the setup process to create a RAID0 drive. Once created, your Mac should pop up a window telling you that it has detected an uninitialized disk and ask what you want to do. You can go into Disk Utility to partition/format the new RAID0 logical drive and once that completes it will mount the drive, making it ready to use.
I just got off the phone with Promise and I had to beg them to walk me through the steps. I called technical support for a reason. The guy on the phone sounded like a complete donkey. Now I know it's only one guy but c'mon,. I'm calling because I don't know. I rather be safe then screw up my $1400 purchase. I hope I don't have a problem down the line with the unit because I'm afraid to call back.
I just got off the phone with Promise and I had to beg them to walk me through the steps. I called technical support for a reason. The guy on the phone sounded like a complete donkey. Now I know it's only one guy but c'mon,. I'm calling because I don't know. I rather be safe then screw up my $1400 purchase. I hope I don't have a problem down the line with the unit because I'm afraid to call back.
Unfortunately, that seems to be par for the course with Promise support. Many consumer reviews complain about them in that regard.
Unfortunately, that seems to be par for the course with Promise support. Many consumer reviews complain about them in that regard.
It's terrible. I'm spending all this money on a product and I'm treaded like that. I thought customer service people are supposed to be friendly and say sure I can help you walk you through the steps..not the customer has to beg
It's terrible. I'm spending all this money on a product and I'm treaded like that. I thought customer service people are supposed to be friendly and say sure I can help you walk you through the steps..not the customer has to beg
What are you stuck with? I just watched https://www.youtube.com/watch?v=SsT6vO01C1w and the steps are what I had mentioned previously.
- Delete existing RAID5 logical drive
- Create new RAID0 logical drive
The video also goes through the step of deleting the array and recreating it, that's not necessary however it is good to see what's involved with the various procedures.
I'm not stuck I just wanted to make sure I was doing the correct steps to be safe.