I plan to do a server with 2 SSDs in RAID1 (for OS and boot) and 3 HDDs in RAID5 (for data). All Linux (CentOS7) with mdadm.
We have in the office 2 leftover SSDs, but they are from different manufacturers and with different capacities (120G and 250G).
I have been reading about RAID1 on SSDs lately and my worries are:
When I create the raid, mdadm will insist on syncing it.
- Both SSDs have been used before. What exactly will mdadm sync when the cells of the two SSDs contain different data anyway?
- Why is that syncing even necessary?
- Does it shorten SSD's life (writing on all cells)?
The
fstrim
command will be issued by a weekly cron job on/
, which will be the mount point of/dev/md0
, which will be the RAID1. Recent versions of mdadm will pass through the trim to the individual hard disks themselves. However, I have read that different SSDs may have different strategies when trimming. For example, one SSD may immediately fill the cells with zeroes, while the other may not. That would mean that the two disks are now out of sync. Now, mdadm has a cron job that, by default, runs periodically and checks the consistency of RAID1 arrays. Will that check report failure because of different trim behaviour?
You can disable the initial sync with the
--assume-clean
option but it is highly recommended to not use this in normal circumstances.What it does is reading each block allocated for the
mdadm
array filling the blocks with zeros and metadata. This also ensures that all blocks are once touched and ensuring all blocks are intact. So you should really run the initial sync.Each block is touched once, so it will lower the lifetime of your SSD. But if you worry about a single write of each block could reach the end of the SSDs lifetime, it is about time to get a new one.
Concerning the
fstrim
and strategies when trimming, I guess you mix upfstrim
and the manufacturer specific wear-leveling.fstrim
is a operating system/filesystem operation, indicating the block device that specific blocks can be freed. Normally when you delete a file, only the inode and directory entry is de-referenced.fstrim
also frees all blocks that were allocated by that file.fstrim
. Some manufactures do not write zeros to the blocks immediately but collect more operations and maybe distribute them over time to keep the performance impact low. This process is also not visible to the OS and should not lead to errors unless your disk has an issue or bug.