Migration from RAID1 to RAID5 turned out to be many times easier than I thought 🙄 In general they are 5 simple little wait steps and 1 a beer for courage.

For me, the system has been created RAID array md0 in which they participate 2 sda and sdb disk. I will add a 3rd sdc to them to create RAID5 from 3 disk. In general, this acrobatics is for the scientific purpose of a virtual I have not yet tested it in a real environment, but I don't expect dramas on a real machine when the time comes.

  1. We create the same file system layout as on our other disks – sfdisk -d /dev/sdb | sfdisk /dev/sdc
  2. We are upgrading our current RAID5 array – mdadm –grow /dev/md0 –level=5
  3. We add the new disk to the array – mdadm –manage /dev/md0 –add /dev/sdc . Here comes the thin point that the array is still RAID1 and will not start syncing because our new drive is spare
  4. The most important moment sdc becomes active and synchronization begins – mdadm –grow /dev/md0 –raid-devices=3 . Good time to open your beer if it is not done 😉 Do not interrupt the process under any circumstances!!!
  5. After the synchronization is over, it has to resize the partition because the loss of space in RAID1 is 1 / n and in RAID5 is 1-1 / n

The biggest bonus is that there is no need to restart the system or remove and create additional arrays.

sfdisk -d /dev/sdb | sfdisk /dev/sdc
mdadm --grow /dev/md0 --level=5
mdadm --manage /dev/md0 --add /dev/sdc
mdadm --grow /dev/md0 --raid-devices=3
resize2fs /dev/md0

Good evening 😛

English: This is a side view of the read head ...

Yesterday I had to boot a Windowds virtual machine NTFS my share. To my great surprise, the machine started dragging an awful lot when virtualbox started creating its virtual HDD. WFT ??? Immediately a quick top and the problem shone. ntfs-3g was crashed on 100% cpu usage 3 of my 6 cores. Hmmm foreign. After a contemplation in the following line, the problem shone through

/sbin/mount.ntfs-3g /dev/sda4 /media/disk1part4 -o rw

Obviously / dev / sda4 is mounted with default options only. In general, the ntfs driver has dirt with intensive writing and reading on the partition if it is not provided with some miraculous settings.

  1. big_writes – the most important option to drop the load intensity of your system using large block recording.
  2. noatime – speeds up the system by disabling inode updates access time if we don't need it. Personally, I don't need it at all
  3. windows_names – there is no acceleration here but on the other hand the file names are treated according to the MS conventions in which the file names, regardless of whether they are uppercase and lowercase, are the same.

After I fixed the options with which my partition is installed fstab the record looked like this

UUID=2213f519-f980-42bf-9e25-9201db38c458  /media/disk1part4  ntfs-3g  defaults,big_writes,windows_names,noatime 0 0

Enhanced by Zemanta