And Promise tech support is worse. Why? Let's talk about this total piece of garbage.
I bought this thing around a month ago. I populated it with
three 750 GB Seagate NS series drives. First thing I notice is this thing isn't quiet enough. At 30 feet, I can still hear the fan. Already I'm unhappy with it. Installed the software to access the unit (I hate installing software to gain access to a WEB gui!!). Also, I needed to change my IP address to a 192.168.0.x address (as expected) to reach the unit. Opened the web interface, reconfigured network, configured device as RAID-5, and rebooted the unit. First notice, web interface is fine, but lacks detailed information for the system status. That point would become more troublesome later. Setup shares for Windows and NFS, and start access the device. Initial thoughts on usage is that store rates are rather slow. After several attempts, speeds drastically increase, but then drop back down again. Why? I'll never know.
Next came the start of my real troubles: hard drive bad sectors.
One of the Seagate drives started exhibiting troubles, but yet the RAID never failed the drive. Not good. The unit stated everything was healthy and functional. Great. However, the so-called "eventlog" would *sometimes* be littered with the following:
Nov 5 11:58:39 WARNING BSL log disk 2 at LBA 0x0564f4fb1 cleared
Nov 5 11:58:39 WARNING BSL update on disk 2 at LBA 0564f4fb1
Nov 5 11:58:39 WARNING Task 20 disk error on disk 2 at LBA 0x0564f4fb1 (Length 0xa) with status 51
Nov 5 11:58:29 WARNING BSL log disk 2 at LBA 0x0564f4fad cleared Nov 5 11:58:29 WARNING BSL update on disk 2 at LBA 0564f4fad
Doesn't look very healthy to me. Neither did the sound of the drive during these attempted writes. R/W performance also halted basically during those events.
At this point, I'm already feeling completely unsafe with this product, but boy was I over-estimating this thing as you'll soon see.
I add another 750 GB that I thoroughly tested before hand for 48 hours using a linux tool called 'badblocks'. Next I pulled the bad one, and the RAID rebuilt fine after 11 hours, as shown below:
Nov 9 08:55:30 INFO RAID status: "FUNCTIONAL". The NS4300N (thegrid) volume "/VOLUME1" is functioning correctly.
Nov 9 08:55:29 WARNING Rebuild on array 1 completed
Nov 9 07:48:18 WARNING Rebuild on array 1 90%
Nov 9 06:41:02 WARNING Rebuild on array 1 80%
Nov 9 05:33:40 WARNING Rebuild on array 1 70%
Nov 9 04:26:24 WARNING Rebuild on array 1 60%
Nov 9 03:19:03 WARNING Rebuild on array 1 50%
Nov 9 02:11:42 WARNING Rebuild on array 1 40%
Nov 9 01:04:26 WARNING Rebuild on array 1 30%
Nov 8 23:42:21 WARNING Rebuild on array 1 20%
Nov 8 22:34:38 WARNING Rebuild on array 1 10%
Nov 8 21:27:00 WARNING Rebuild on array 1 started
Nov 8 21:27:00 WARNING Disk 2 unplugged
Nov 8 21:26:56 WARNING RAID status: "CRITICAL". The NS4300N (thegrid) volume "/VOLUME1" is not functioning correctly.
No more troubles right? Wrong. Several days go by, continuing to move data from older non-raided drives to this unit at a blazing speed of around 5 MB/sec (ha), when all of a sudden the filesystem goes read-only, and won't go back to read-write without a reboot. I could repeat this scenario several times throughout a day. What the heck is wrong with this thing? "Eventlog" say nothing:
Nov 17 19:31:14 INFO System is starting to work.
Nov 17 19:29:11 INFO System is rebooting.
Nov 17 19:04:57 INFO System is starting to work.
Nov 17 19:03:03 INFO System is rebooting.
Nov 17 18:53:39 INFO System is starting to work.
Nov 17 18:51:27 INFO System is rebooting.
Nov 17 18:10:45 INFO System is starting to work.
Nov 17 18:08:46 INFO System is rebooting.
Well, that's not good of the device to not report a problem. Darn it, this thing sucks. I want it fixed, this is a poor quality product. So next I log a case with Promise Support on the web. I get an email back with a case number from an automated system. The case details I put were as follows:
My NS4300N has been giving me trouble lately. I purchased it 16 days ago, running three Seagate 750 GB drives in RAID-5 configuration. One of the 3 drives had bad sectors and was not being failed by the NAS, but I replaced it with a known new good drive (tested with linux util badblocks for over 48 hours), replaced over a week ago. Now I am regularly having problems with the mounted filesystems going Read-Only, however the event log does not show anything. When this happens, my only solution is to reboot the unit, which appears to trigger on restart a filesystem check (longer boot time than a reboot when working fine). I suspect that there are filesystem troubles, but there is no way I can test that or see that. Event log only shows:
.... same as above.....
As you can see from the timestamps, I can pretty readily fail this device.
Please advise.
The next day, I call to check on the status. I am told an engineer will call me back. An hour later one does, I explain what's going on, and he tells me to backup my data and reformat this sucker. Well isn't that just great. I say no, I want to find the problem before I have to do that extreme measure. Frankly, if this can't be fixed any other way, I won't be using this product. He says he can't get into the linux kernel level, and I say find someone who can. The net result is that he closed the case on the me the next day with the following solution:
Case Solution:
Hi, Try moving all the data off the unit and deleting and recreating the array. It might be compromised because of the bad disk. The integrety of the array might be failing. Move the data and delete the array and recreate it so it creates the nfs filesystem over.
Completely unacceptable. Thanks Promise support for closing my case without my ok! Thanks Promise for not investigate my problem! Thanks Promise for providing a useless solution to a problem that may, and probably will, occur again taking my data with it!
With some deduction, and a little help from the web and an exploit, I can pull the "real" dmesg output from this device, something Promise support could not/would not do :
eth0: Link is up
eth0: Flow control is on
EXT3-fs error (device dm-0): ext3_new_block: Allocating block in system zone - block = 247889925
Aborting journal on device dm-0.
EXT3-fs error (device dm-0) in ext3_prepare_write: Journal has aborted
ext3_abort called.
EXT3-fs error (device dm-0): ext3_journal_start_sb: Detected aborted journal
Remounting filesystem read-only
EXT3-fs error (device dm-0) in start_transaction: Journal has aborted
__journal_remove_journal_head: freeing b_committed_data
__journal_remove_journal_head: freeing b_committed_data
This isn't good at all. Either the filesystem has corruption (maybe in the superblocks) or the kernel has bugs. For the former, shouldn't the RAID-5 have protected against this??? Yeah, one would think. Great product, real great product.
Needless-to-say, I'm tossing this lemon. Picking up a RocketRAID for a little more than this thing cost, and running RAID-6 on my own linux, where I'll get useful things like disk-scrubbing, real event logging, and S.M.A.R.T. data, you know, things to actually PROTECT your data.
