yudi v wrote: > I am looking at using Debian software RAID mirroring and would like > to know how it handles system crashes and disk failures. It handles it quite well. > My only experience with software RAID 1 is with windows 7 inbuilt > option. Whenever the system does not shutdown cleanly, upon reboot > the disks start resynching and the whole system becomes very > sluggish, almost impossible to use. Depending on the size of the > disks, this can be quite long (I am guessing this is because it is > resynching at the block level). If a resync is needed then the entire time to complete depends upon how much data needs to be sync'd and how much data I/O bandwidth is available from the hardware. Large disks can take a while regardless of the system. > I was speaking with someone using freeBSD/ZFS and they reckon ZFS > does not resynch after a crash and when a disk is replaced it only > copies data not each block. > > How does linux software RAID 1 handle these two scenarios? In my experience, and I just experienced a power out crash of three RAID1 systems yesterday, most of the time the array will remain in sync after a crash. All three of my power crashed systems yesterday remained in sync. This probably depends upon the activity level of the systems. A system that is more idle will be less likely to experience this. Or rather a busy system is more likely to experience this and need to be sync'd. Note that you can change the Linux kernel software raid sync speed limits by setting dev.raid.speed_limit_max. $ cat /proc/sys/dev/raid/speed_limit_min # echo 50000 > /proc/sys/dev/raid/speed_limit_min Can do better with: # echo 500000 > /proc/sys/dev/raid/speed_limit_min The Linus software raid also had the capability to use a block bitmap to speed up resync after a crash because then it tracks which blocks are dirty. See the documentation on this mdadm command to configure an internal bitmap to speed up a re-sync after an event such as a power loss. mdadm /dev/md1 --grow --bitmap=internal This does not speed up an array check which must by definition check all of the blocks. But it will speed up a full rebuild after a power outage. Requires --detail to report that the superblock is persistent and the array active. I was only using the bitmap on one of the three machines that had the power out yesterday. The other two machines were mostly idle and survived the power cycle without needing an array sync regardless. Note that after a power cycle even if the RAID 1 array needs to be sync'd between the mirrored disks that the system will still boot okay and will operate normally. I have no idea what other systems do but you can boot the system, log in, and it will perform its normal tasks. If the array needs to be sync'd then it will sync in the background. This is why the kernel implements the speed_limit_max values so that normal system operation will not be starved of disk bandwidth. You might not notice that it is doing this. It might finish the task without impacting normal system functions. During the hours when the disks are out of sync a disk failure would not have redundancy however. Therefore getting the system back in sync again should be a priority to restore the redundancy of RAID. I usually partition the disk into partitions no larger than about 250G each. A 1T disk I would set up with four 250G partitions. Then use them as physical extents for LVM all combined together into a single 1T volume group. Then use that to create logical partitions as desired. The advantage is that if a disk fails and needs to be replaced that each 250G partition is sync'd independently. And due to LVM if the disk is not full the extra partitions may not be used and may not need to be sync'd. However the steady state of disks is full and therefore I am never able to reap that benefit. The only real gain is that as the raid1 sync proceeds the individual partitions can be checked off as done on the scoreboard as incremental progress along the way. A subsequent reboot while the sync is proceeding would not restart at the beginning for mirrors that are back in sync again. Bob
Attachment:
signature.asc
Description: Digital signature