4

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:

  1. When I create the raid, mdadm will insist on syncing it.

    1. Both SSDs have been used before. What exactly will mdadm sync when the cells of the two SSDs contain different data anyway?
    2. Why is that syncing even necessary?
    3. Does it shorten SSD's life (writing on all cells)?

  2. 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?

Pavel Tankov
  • 367
  • 3
  • 15

1 Answers1

1

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 up fstrim 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.
  • wear-leveling is the method of the SSD itself how it handles the freed blocks indicated by 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.
Thomas
  • 4,155
  • 5
  • 21
  • 28
  • 2
    This did not answer the question about inconsistencies between the two devices after trim, causing errors during resync. – Ariel May 22 '20 at 05:50
  • I *think* it answered the question but was not explicit. I believe that the device will return zeros when reading a block that has been trimmed, whether or not the wear leveling has actually zeroed physical media that used to be associated with that block. Is that a consistent behavior? Do all drives always return zeros on trimmed logical blocks? – vontrapp Aug 14 '22 at 23:54