Optimal RAID 6 Configuration for 72GB Drives in Source Control & SQL Dev Environments


2 views

When setting up a development server with 6x72GB drives, the choice between RAID 5 and RAID 6 comes down to fault tolerance versus performance. For source control repositories and development SQL servers, data integrity is paramount.

RAID 6 provides dual parity protection, allowing two simultaneous drive failures without data loss. This is crucial when dealing with:

  • Frequent commits in version control systems
  • SQL transaction logs
  • Continuous integration builds

While RAID 6 has higher write overhead than RAID 5, modern hardware RAID controllers mitigate this. The IBM server's controller should handle the parity calculations efficiently. For read-heavy operations (common in source control), RAID 6 performs comparably to RAID 5.

Here's how to configure RAID 6 using Linux's mdadm:

mdadm --create /dev/md0 --level=6 --raid-devices=6 /dev/sd[b-g]
mkfs.ext4 /dev/md0

For SQL Server development, consider placing tempdb on a separate volume. With RAID 6, you might create:

mdadm --create /dev/md0 --level=6 --raid-devices=4 /dev/sd[b-e]
mdadm --create /dev/md1 --level=0 --raid-devices=2 /dev/sd[f-g]

Implement regular monitoring to catch potential failures early:

cat /proc/mdstat
mdadm --detail /dev/md0
smartctl -a /dev/sdb

If your OS supports it, ZFS offers excellent RAID-Z2 (similar to RAID 6) with additional features:

zpool create devpool raidz2 sdb sdc sdd sde sdf sdg
zfs set compression=lz4 devpool
  • Use RAID 6 for primary storage (source control, SQL data)
  • Consider RAID 10 for high-performance SQL tempdb if splitting arrays
  • Schedule regular array scrubs (monthly for RAID 6)
  • Monitor SMART attributes proactively

When dealing with legacy hardware like your IBM server with 6x72GB disks, we need to consider both the physical limitations and modern development requirements. The small disk capacity actually works in our favor for certain RAID configurations by keeping rebuild times manageable.


# Sample Linux mdadm commands for comparison
# RAID 5 with 6 disks (5 data + 1 parity)
mdadm --create /dev/md0 --level=5 --raid-devices=6 /dev/sd[b-g]

# RAID 6 with 6 disks (4 data + 2 parity) 
mdadm --create /dev/md0 --level=6 --raid-devices=6 /dev/sd[b-g]

# RAID 10 with 6 disks (3 mirrored pairs striped)
mdadm --create /dev/md0 --level=10 --raid-devices=6 --layout=f2 /dev/sd[b-g]

For Git repositories, RAID 10 provides the best random I/O performance for numerous small commits. Here's why:

  • Faster git status operations due to mirroring
  • Better handling of concurrent git push/pull operations
  • No parity calculation overhead during intensive operations

Development SQL servers have different requirements:

RAID Read Speed Write Speed Fault Tolerance
5 Good Medium 1 disk
6 Good Slow 2 disks
10 Excellent Excellent 1 disk per mirror

Given your mixed workload, I recommend creating two separate arrays:


# For SQL data (RAID 10 for performance)
mdadm --create /dev/md0 --level=10 --raid-devices=4 /dev/sd[b-e]

# For source control (RAID 6 for capacity)
mdadm --create /dev/md1 --level=6 --raid-devices=2 /dev/sd[f-g]

Don't forget to set up monitoring for your arrays:


# Add to cron for daily checks
echo '#!/bin/sh
mdadm --detail --scan >> /etc/mdadm.conf
mdadm --detail /dev/md0 | mail -s "RAID Status" admin@example.com' > /etc/cron.daily/raid-check