DSM-G600, DNS-3xx and NSA-220 Hack Forum

luusac wrote:

which drive did you pull lhs or rhs?

I had pulled the LHS (volume 2). I am using it for redundancy/reliability, using backup software to back up to it. I have seen the posts talking about automatic copying of data from one volume to another... maybe now I'm beginning to see why you'd do that.

Thanks,
Bill...

RAID1 or RAID5 (in fact, any RAID implementation other than RAID0) should appear exactly the same to an end user - if a single drive fails or is pulled from the system to simulate a failure (assuming it is safe to do so from a hardware standpoint), the end result should be the same, that data should remain available and there should be some sort of alarm or other error indication that a failure had occurred.

By way of explanation of the - assuming it is safe to do so from a hardware standpoint - certain physical drive interfaces were not designed for hot plugging and any attempt to pull a drive to simulate a failure could well result in catastrophic failure of the hardware - these include the old ST506/412 & ESDI interfaces, IDE/ATA also known as parallel ATA and the 50 & 80 pin SCSI interfaces - these all use ribbon cables with relatively high numbers of connections.  On the other hand, SCSI interfaces using the SCA & SCAII connectors, SAS (Serial Attached SCSI) and SATA )Serial ATA) were all designed with hot plugging in mind and it is safe (again from a hardware stand point) to remove a drive with power applied.

In most of the RAID1 (and RAID5) environments I have worked with it is possible to "yank" a drive without bringing the system down, and to wipe all data & partitions from that drive and re-insert it and allow it to rebuild - please note the rebuild may or may not start automatically - it depends on the RAID controller - and in my initial tests with the DNS-323 this is exactly what I did, and it worked flawlessly.

For those of you who may have noted that I earlier said "most of the RAID1 (and RAID5) environments - I have discovered that parallel ATA disks do not adapt well to RAID environments - especially if you build a RAID1 array using a master/slave pair on a single cable - often times if the slave fails, the system will freeze momentarily (whilst the controller - which is actually on the "master drive" figures out that the slave has died) and if the master fails, the system will more often than not, crash (the disk controller on the master died).  I've also seen what are known as "punch through" errors, where errors on one drive can cause errors on another drive - again because of the shared controller.

Now - although the DNS-323 uses SATA disks which support hot plugging, the unit itself does not support hot swap and as a result it will not automatically rebuild a failed disk - in my simulations I inserted the newly cleaned disk and after powering up and logging into the admin interface, the unit prompted me to format the drive, which I did, after which it resynched successfully.

I have seen horror stories from folks who say they lost all their data when the unit formatted the wrong disk, but the only way I was able to provoke this is to use a disk with data on it as my "replacement disk" - please note - this was a deliberate attempt to simulate a data loss scenario, and not something I would normally do, having learned, many years ago that it was a sure fire way to lose data.

It was my original intent when the DNS-323 was released, to use it as a RAID1 box in a number of very small businesses, however, I have not gone that route as the RAID1 implementation does not appear to have the reliability my clients would need.

I agree with blahsome - what wrlee tried to do should have worked - and when I tried it, it did work.

Thank you, fordem for the explanation. I am not sure what had happened; I wasn't _hot_ swapping the drives (I didn't know it was safe to do that!)... I had shutdown and removed the other drive. It could have been a glitch or maybe I didn't realize that the drive was still rebuilding (although it was the secondary drive I'd removed, not the primary).

Can you elaborate (or refer me to info) on the issues that make the 323 _not suitably reliable_ as a RAID 1 implementation?

Is RAID1 supposed to be able to circumvent I/O errors in a sector of one drive (by reading corresponding sectors of the other)?

Bill...

jesbo wrote:

I would expect to be able to simulate a drive failure by pulling it out, deleting partitions or erasing it on another machine, and reinserting it - at which time it should be rebuilt and brought in sync with the still-good drive. This does not have to be automatic (as in RAID 5), but the unit should still preserve all data on the good disk and provide the facility to re-mirror to the new drive and reestablish the RAID-1 mirror.

Even in RAID5 a rebuild is not automatic - I have had installations that were RAID5 on LSI logic MegaRAID controllers where you manually had to select the replacement drive and start a rebuild.

For a RAID array to be deemed functional, all that is required is that the data continue to be available in the event of a failed drive, how the array is restored to an optimal condition is left up to the manufacturer's discretion.

Automatic rebuilding, remirroring or resynching - like hot swap - are highly desirable features but are not mandatory.

bq041 wrote:

Their error checking of the array is also flawed....  I do not use the web setup anymore for any disk related activities.  I have repeatedly broken and rebuilt arrays on the DNS easily 50 times without any data loss.  The key to making the dlink web interface happy with this is proper setting of a few files that DLink looks at (raidtab, raidtab2web, hd_magic_num).

Thanks!  I initially created my RAID-1 using the web interface (when the unit was new and I was a DNS-323 noobie). Since then, I've implemented ffp and now have full access and can use mdadm from this point forward.  Are there any tweaks to the files you mention that one should make?  Pointers / explanations welcome.