Well, at least at 1.05, 1.06 and 1.08, I have seen it re-sync, can repeat this anytime. As far as I know, this is a kernel feature, and Dlink has not updated the kernel for a long time. If DLINK had done anything to change this behavior of re-sync and fsck, then, the data in the RAID1 array will never be able to guarantee integrity. As far as I know, Linux md driver do not have any facility to disable 'resync' because it is a dangerous thing to do (read details of md options here:
http://www.gelato.unsw.edu.au/lxr/source/Documentation/md.txt).
I think there
may be a confusion about Auto-Rebuild in the configuration menu and re-sync. I believe DLINK's 'rebuild' means partitioning and 'formatting' the drive. Formatting only make sense when the drive inserted is not part of a RAID1 array. If the drive is meant to be a spare disk for a degraded RAID1, then, 'rebuild' only mean partitioning and hot add the spare disk in the RAID1 array. The md driver will take over from there to perform the resync, where the resync status can be seen on the status page.
If DLINK wants to make live less stressful for all, then, update the kernel, and allow option to activate 'write_intent_bitmap' for those who care more about data integrity and willing to suffer yet a little more performance, all in the name of avoiding lengthy re-sync, especially for large capacity drives.
Anyway, this is besides the point - I was trying to alert that by design, the RAID sub-system of Linux does re-sync when any
writes to any disk component that is part of a raid array was lost before the commit set is able to fully complete.
Why you had not seen it re-sync is most probably that a write was not pending, so you were lucky. It takes a write to RAID array at the time of power trip to result in 'mismatch'.
Even more important point I was alluding to the fact that ext2 by design will need a fsck if the power is lost without a proper shutdown. This is the major flaw in ext2 design, and thereafter the journalling was added to ext3 to fix this deficiency and annoyance.
If RAID1 array host a ext2 file system, a RAID level re-sync is not sufficient to assure integrity of data. In fact, it is very dangerous - files may ended up cross -linked badly.
Firmware prior to 1.08 does not have means to 'scandisk'. If the internal file system is left at ext2, i.e. not migrated to ext3, then, whenever power trips, it is highly advisable to scandisk. Otherwise, do frequent backup, but be very careful whether you are backing up files that have already been crossed linked. In other words, the backup may succeed, but what went in are actually corrupted versions of files.
If data integrity is top of your list, then consider reconfiguring the RAID1 array to host ext3 file system. However, be aware that you loose some performance, this is the price you pay - buy data integrity with some throughput. For most real-world applications, the little lost in performance is insignificant.
On the throughput, yes, in fact, all 4 of my DNS323 does the job at at 89MB/s sustained throughput when re-sync'ing. However, note that this rate is achievable for the first 40% of the disk capacity, then, it will gradually drop by 10% towards the higher end of the capacity rating. To re-sync fast, you must not have any service running, especially services like FireFly, any disk activity on the RAID will affect the throughput. Therefore, to swap out a disk from RAID array, it is best done when none of the services are needed.
