On Aug 20, 2009, at 10:33 AM, mcclnx mcc <mcclnx at yahoo.com.tw> wrote: > we have DELL server (CENTOS 4.X) with MD1000 connect on it. One of > Raid5 (internal 4 disks) has hard disk bad and I replace it. I saw / > var/log/messages have following entry: > > ======================================= > Aug 18 15:33:20 host1 Server Administrator: Storage Service EventID: > 2049 Array disk removed: Array Disk 0:11 Controller 1, Connector 0 > Aug 18 15:34:09 host1 Server Administrator: Storage Service EventID: > 2052 Array disk inserted: Array Disk 0:11 Controller 1, Connector 0 > Aug 18 15:34:09 host1 Server Administrator: Storage Service EventID: > 2065 Array disk Rebuild started: Array Disk 0:11 Controller 1, > Connector 0 > Aug 19 00:42:58 host1 Server Administrator: Storage Service EventID: > 2124 Redundancy normal: Virtual Disk 0 (Virtual Disk 0) Controller > 1 (PERC 4e/DC) > Aug 19 00:42:58 host1 Server Administrator: Storage Service EventID: > 2092 Array disk Rebuild completed: Array Disk 0:11 Controller 1, > Connector 0 > Aug 19 00:45:53 host1 Server Administrator: Storage Service EventID: > 2127 Background Initialization started: Virtual Disk 0 (Virtual > Disk 0) Controller 1 (PERC 4e/DC) > > ============================================= > > My questions are: > > 1. why after "disk rebuild" there have "background initialization"? The rebuild resilvers the new disk based on the existing parity information while the second pass updates segments based on new parity information that may have been written before the resilver process finished, for a RAID1 it would be to mirror blocks that were updated during the rebuild. This is because a disk doesn't participate in an array until it is rebuilt. > 2. is all kind of configuration (e.g. RAID0, RAID10, ...) need > perform "background initialization"? RAID 1 and above. > 3. if I run heavy application, will it hurt "background > initialization" and "disk rebuild"? Yes, of course, I usually set rebuild rate to 100% because I'd rather slow IO during a rebuild then risk a possible double failure during a slow rebuild. -Ross