Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
Afternoon all,
I bought a DNS 323 and a couple of 500Gb HDs to stick in it with the intention of creating a RAID-1 array.
Today I have been testing the effectiveness of this RAID.
I transfered 200Gb of data to the NAS. Pulled HD2 out (right) and connected it to my desktop machine. I was able to read the EXT2 file system and browse my data as well as continue to use the NAS - this is good but what I expected.
I then wiped clean HD2 and put it back into the NAS which then said it needed to reformat and resync my drives..so far so good.
1.5 hours later I returned to see the process complete but to my horror discovered half of the data missing ... what could have gone wrong here?
I'm using firmware 1.02b114 which is the latest (for EU).
Offline
Actually the right slot is Drive_0 - not that it should make a difference to how the RAID works.
Apart from that , I have a question for you - was the missing data there when you has the drive out? I've not had problems losing data when doing tests such as you have, although I just realised that I've never pulled the drive in the right slot, which like I said should not make a difference.
Offline
Nope, ALL data was available through the NAS with only the 1 drive attached in the left slot, the data was subsequently lost during the (re)synchronization process. This may have only been a test so I didnt really lose any data but had I just trusted this device and filed all 500Gb I wouldn't be too happy right now. RAID-1 was one of the big selling points of this device for me.
Offline
Agree with you entirely on that.
Like you I have not lost data, but I have seen glitches and no longer have the confidence in the unit to use it as I had first intended.
Offline
RAID-1 functionality is not properly implemented in DNS-323, I ran tests on the previous firmware from the command prompt (there is an early thread describing them) and it failed. From the failure type it seems to be stemming from an unfortunate mix between SATA controller driver issue and poor RAID recovery script implementation.
But just before you start contemplating about future fixes- I had a case this week where server running two Maxtor disks for 2.5 years in RAID 1 crashed after both disks failed within 8 hours of each other. These disks failed for different reasons, no external influence such as high ambient temperature or power spike, neither excessive load, pure damn coincidence.....
But I have seen this for the very first time in my long IT career.
SD
Offline
Skydreamer - I'd be interested in knowing the "different" reasons for those drive failures, as well as how you determined them.
Like you, I have been in the business for many years, and I know from experience that losing both drives in a RAID1 array withing a few hours of one another can happen, but is a relatively rare thing - in fact the only time I've seen it happen, we traced it to a production batch issue - many of the drives from that batch failed within the same time period - of course no manufacturer likes to release that sort of information, I knew about it because I was employed by the manufacturer at the time.
Offline
I've had a cursory look at your post history and can't see the thread in question (firmware tests), could you post a link to it?
What about 1.03?
Suppose I could use JBOD for 1Tb of storage and manually backup onto other hard drives...I do hate that M word.
I've raised an incident request with DLink anyway, let's see what they say.
Offline
http://dns323.kood.org/forum/t132-Anyon … ality.html
Would this be the thread referred to?
Offline
Could be, could be.
I was just reading this one http://dns323.kood.org/forum/t133-Raid- … dmesg.html
I didn't pay £160 to learn Linux though and I've already spent a significant proportion of my weekend playing around with this thing. It's not the end of the world; the media and print servers work well, performance is acceptable and its got really cool flashing blue lights.
Offline
Fordem- yes, the thread is correct.
One of the disks had problem with the heads servo mechanism and was returned to Maxtor, the other one suffered CRC unrecoverable read errors but after "low level" zeroing the contents it passed three days running burnin' test.
I recently read an interesting article from Google itself, they are one of the biggest single users of hard disks and claimed that they found NO link between the disk failures and ambient temperature or disk load. Which leaves us with manufacturer and bad batch and this corresponds to my findings- I have access to disk return rates of a large IT disty and always check the latest data before buying new disks for internal company use. Every major disk manufacturer produces a bad batch once in a while and quietly collects the failing disks. A reasonable rate of failure is below 3% but I have seen this figure to grow to 30-35% on some very popular disks....
Offline
Ambient temperature, hmmm - I might have to differ from Google on that, although they would definitely have a larger pool of experience to draw from. In my experience, elevated operating temperatures can dramatically shorten disk life, and operating temperature will never be lower than ambient, although it could be significantly higher.
Offline