Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
After all the months of posts with people having problems, I was wary of trusting my DNS-323 in a RAID 1 setup. I've used this unit for close to a month, and as I prepare to delete my original data from other devices I figured I should really run this thing through some thorough testing.
Please note that I have little to no knowledge (or interest) of hacking into this box to really confirm that things are properly working behind the scenes (as described in this previous thread). All my tests are done with normal use of the DNS-323, and may be replicated by anyone with modest computer knowledge.
My specs:
DNS-323 with 1.02b firmware, set to RAID 1, formatted w/ EXT2
Two drives: 500GB Maxtor MaXLine Pro 500, Model 7H500F0
345GB of data (5,148 files with 348 folders, largest file = 1.6GB)
---------------------------------------------------------------
Test 1: RAID 1 Mirroring
---------------------------------------------------------------
Goal: To confirm that data is indeed identical on each drive.
Procedure:
1) Turned off DNS-323, pulled out left drive
2) Turned on DNS-323
3) Checked status via web interface - OK
4) Checked file access - OK
5) Turned off DNS-323, replaced left drive, pulled out right drive
6) Turned on DNS-323
7) Checked status via web interface - OK
8) Checked file access - OK
Conclusion: The data has been properly mirrored to both drives. However, there was never any indication of a drive failure (other than the blue LED light for the drive was off). This is concerning that there isn't any better notification of a failed/missing drive... perhaps pulling a drive out does not properly mimic a failed drive, and that in the case of an actual failed drive the unit would notify you.
---------------------------------------------------------------
Test 2: Resyncing Out-Of-Sync Drives
---------------------------------------------------------------
Goal: To test resynchronization of drives when one drive is pulled, the DNS-323 writes new files, and the pulled drive is replaced. This isn't considered a good idea, as it can cause data corruption between the drives (thanks frodo).
Procedure:
1) Turned off DNS-323, pulled out right drive
2) Turned on DNS-323
3) Checked status via web interface - OK
4) Copied a 20MB file to the unit
5) Turned off DNS-323, replaced right drive
6) Turned on DNS-323
7) Checked status via web interface - OK
8) Checked for newly copied file - it's not there
Conclusion: Looks as if it is possible to "lose" files if you remove one drive and add it back in later. Again, this test could compromise your data integrity.
---------------------------------------------------------------
Test 3: Restoring Mirrored Data After Drive Failure
---------------------------------------------------------------
Goal: To test proper resyncronizing of drives when one drive is replaced with a new, unformatted drive.
Procedure:
1) Turned off DNS-323, pulled out left drive
2) Connected left drive to another system, deleted all partitions and formatted drive
3) Replaced left drive
4) Turned on DNS-323
5) Checked status via web interface - upon logging in, message came up that "the new drive must be formatted"
6) DNS-323 formatted drive, restarted
7) Checked status via web interface - gave a "Sync Time Remaining" estimate of 120 minutes
8) Checked file access while syncing - OK
9) After two hours, checked status via web interface - "Sync Time Remaining" shows "Completed"
10) Turned off DNS-323, pulled out left drive
11) Turned on DNS-323
12) Checked status via web interface - OK
13) Checked file access - OK
14) Turned off DNS-323, replaced left drive, pulled out right drive
15) Turned on DNS-323
16) Checked status via web interface - OK
17) Checked file access - OK
Conclusion: The DNS-323 successfully rebuilt the blank drive.
---------------------------------------------------------------
Final Words
---------------------------------------------------------------
That's all the testing I needed to feel comfortable with the DNS-323. With the 1.02b firmware, all previous reported problems with RAID 1 seem to have vanished. (My only remaining concern is what temperature the drives run at.)
Last edited by ericwhitney (2007-02-19 05:01:58)
Offline
By first removing one drive. And in the subsequent power replace it and remove the other drive. This could cause you major data corruption on a MD raid 1.
You should always allow for the system to resync between your replacements. This is why your file was missing. After doing the above I would not trust my filesystem with out a re-format.
Offline
Hi frodo,
In the case of Test #2, I believe the file was gone because it re-synced the drives faster than I could check (the file I copied was only 20MB). Your point is well taken though... and thankfully the last thing I did was a complete reformat of a drive, so everything should be back to being identical again.
Offline
Interesting Eric but unfortunately the fact that you have lost a file in test 2 points to a problem.
I have done a couple of tests with the new firmware and my biggest grief is that the filesystem is not coming back clean after the unit restarts. There are always some lost sectors or an incorrect count of free space, which most likely results in a random file loss especially when the RAID1 array runs in degraded mode.
I have the DNS-323 sitting under my desk waiting for another firmware upgrade but as it is I trust Maxtor shared storage more even though it has no RAID functionality and am still using it instead of this half finished box. I am sure they will get it right... eventually.
Also fdisk is still not working....
Last edited by skydreamer (2007-02-19 12:22:30)
Offline
I've done a few tests of my own in this regard and I can tell you that the "disk fail" sensing on the device is sadly lacking.
In addition to the tests outlined by Eric,I have hot unplugged and inserted drives, I have installed KNOWN DEFECTIVE drives and the unit has never once reported a drive failure.
The known defective drives included drives that appeared to be fully functional but reported a SMART error if installed in a PC at startup, and drives with bad sectors - the DNS323 never reported an error, in most cases formatted the drives as if they were good - although the format may have taken longer than normal, and in one case the only indication that all was not well was that the estimated time to resync was 9000+ hours.
Any loss of data that occurred during my tests was caused by me doing things that I know would not be considered normal, and moreso likely to lose data in a hardware RAID environment, in an attempt to force the unit to report a drive failure.
My concern is not so much that I could lose data by fooling around with the drives, but more that a failed drive will go unnoticed, and that WILL eventually lead to lost data.
Offline
The only time I've seen my DNS flag a failed drive error is if I boot the array with only one drive. Then it tells me a drive has failed. No kidding, there's no drive.
Has anyone tried playing with Fonzo's funplug distro of fsck or other kinds of partition/drive scripts? Maybe I can just setup a cron to check the drives and then report errors to the root directory or better yet email me.
Offline
Actually I did manage to get mine to show an amber failure LED once - I had a RAID0 array in it, pulled the drives, reset the box using the pin reset switch, and then re-installed the drives - on power up the right bay LED went amber.
Offline
fordem -
Was that last even a valid failure? Out of curiosity, do you remember if mdadm reported failure on any of those bogus drives you used? If it's just a matter of the dlink software not reporting things correctly because it's not looking at the right output, that's one thing, but if the RAID subsystem itself isn't detecting failure, then there's not much we could expect the dlink software to do beyond that.
ericwhitney -
I can definitely confirm the results of Test 2, as mentioned in another thread (http://dns323.kood.org/forum/t1379-RAID … ssing.html). fordem correctly pointed out that while it won't detect that the drives are out of sync if they were previously members of the same RAID array, inserting a blank drive does cause the array to rebuild correctly. I file this more under the "not a valid use case" and less as a "defect". Though the horrible error detection capabilities are definitely a fault.
Offline
Gambit - back when I was fooling around with defective drives - early '07 - I was not running RAID, having decided that the weakness was not related to the device's RAID capability, but in it's error/failure detection capability - this unit will not detect failing drives whether or not it's in RAID mode - if I'm not mistaken, you can remove either drive in standard mode and it will not even send an email alert.
At that time I was also not sufficiently "linux savy" to know about mdadm and had not even plucked up the courage to fool around with funplug - that didn't happen until a discussion arose on using external USB drives - the folks here are hugely responsible for the limited linux knowledge that I have acquired.
Offline