6

I need to configure a RAID-1 on one SSD and one HDD. Both SSD and HDD has some preinstalled software, which I don't need so both can be fully wiped if that is any advantage.

My research so far lead me to the --write-mostly option, which I understand that I should be using on the HDD such that read operations will get the full speed of the SSD.

But it is not clear to me, how to ensure the TRIM command is properly used.

I read warnings about mdadm writing to every sector of the device during setup leaving the SSD with no spare sectors regardless of any TRIM performed before setting up the raid.

Am I better off first creating the RAID degraded with the SSD as the only device and then adding the HDD, such that only the HDD gets written to?

What would I need to do to the SSD before setting up the RAID, such that any needed TRIM has been performed? The SSD has preinstalled software (that I don't need), which means I don't know which sectors has been previously written.

In case it is of any relevance, the SSD is 128GB and is in dmesg output mentioned as SAMSUNG MZ7LF128HCP-00000, FXT0101Q by the ata layer and SAMSUNG MZ7LF128 101Q PQ by the sd layer.

Improve this question
4

Just use --assume-clean and don't even sync in the first place.

Once you create your RAID, the first thing you do is mkfs... and mkfs TRIMs by default without even asking (unless you use -E nodiscard or similar) and your RAID sync is already gone at this point anyway.

Basically it's impossible to keep a mixed SSD+HDD RAID in sync as long as TRIM affects only one side. Even with SSD+SSD RAID, a TRIM will likely cause differences if it's different SSD models or different partition offsets.

It's not a problem as long as it only affects "free space". The actual data itself will still be in sync and thus redundancy is provided.

If the SSD ever fails or you decide to replace the HDD with another SSD later on, that's where you get the full sync on SSD since that's the only way md knows how to do things. md does not record TRIM commands and thus remember "free" regions to speed up syncing; it is also not smart enough to TRIM (and thereby zero) the target SSD and only write non-zero data. Maybe when SSD become more common such features will be added to speed up resyncs.

Even so it's not something you should worry too much about; TRIM is a long-term measure, your filesystem will see TRIM during regular use, so over time even a fully written SSD will see enough trimmed areas.

Improve this answer
15
  • 1
    As an alternative to --assume-clean, you can just specify the SSD as the first drive, and it will be copied to the HDD instead of the other way around. You also don't really need TRIM as long as you leave a few gb of the drive unpartitioned so you never write to it. – psusi Oct 11 '15 at 18:28
  • @psusi Leaving unpartitioned space won't help if that space already contains data. As mentioned in the question, it came with software preinstalled. And if I rely on mkfs performing the TRIM, it will only TRIM the partitioned space. If the unpartioned space has already been written, and I don't TRIM it somehow, that unpartioned space is not going to help me. – kasperd Oct 11 '15 at 20:10
  • @frostschutz Obviously mkfs can only do the TRIM if I am using a sufficiently recent version of mkfs and of the md driver. How can I tell if mkfs and md driver are recent enough to do the TRIM for me? (Your point about replacing a drive later on is a good one. But I am not going to worry about that for the time being.) – kasperd Oct 11 '15 at 20:26
  • @kasperd if the man page describes the option, it should be recent enough. If in doubt just use kernel 4.x ;-) – frostschutz Oct 11 '15 at 20:29
  • @frostschutz Yeah, that should tell me if the mkfs command supports it. But how about the md driver? – kasperd Oct 11 '15 at 20:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.