Hot answers tagged software-raid
fsck stands for 'file system consistency check', it checks a filesystem, not the underlying disks - as such it should be used to testing the entire filesystem. As for periodic automatic fsck executions look at your /etc/fstab file, it's in that file that we can define automatic checks.
The answer to when to run fsck on the underlying physical disks is very simple: Never If you are using RAID-1 the fsck command might not notice you are using it incorrectly and perform an actual check. If that check results in any writes to the disk, you will end up with a RAID where the disks are out of sync. Having metadata out of sync between RAID ...
RAID1 doesn't work that way. When you added those two new partitions to your array, you added two more copies of the data. You added redundancy, not capacity. At this point you ought to look into either RAID5, which will gain you disk capacity x (number of disks - 1), or something like RAIDZ or btrfs.
The trick is to use right LABELS: Setup SoftwareRAID for the CoreOS root partition Only for ext4! Assume CoreOS is on /dev/sdaX and the second RAID Device is /dev/sdb Drawback: only / gets mirrored, Node goes down when sda fails -- Boot into any recovery system like Grml If not already done: install CoreOS Backup /dev/sda9 mkdir -p /root/sda9 mount ...
Your md3 array is resyncing, that's why it is slow. Based on your smartctl output, sda will fail soon. ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 117 099 006 Pre-fail Always - 162055184 3 Spin_Up_Time 0x0003 092 092 000 ...
I went ahead and just tried it, and the answer is YES. A two-disk RAID5 using mdadm superblock version 1.2 will in fact retain its data upon failure and removal of one of the disks. e.g: mdadm /dev/md0 --fail /dev/sdc --remove /dev/sdc mdadm --zero-superblock /dev/sdc
Only top voted, non community-wiki answers of a minimum length are eligible