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.

kasperd
  • 3,580

1 Answers1

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.

frostschutz
  • 48,978
  • 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
  • @frostschutz The mkfs.ext3 man page mentions both discard and nodiscard options, so that looks good. The install image I am planning on using (Ubuntu 14.04.3) has kernel version 3.19.0. So I am still wondering if that kernel version has an md driver new enough to pass on the TRIM commands from mkfs to the physical drive. – kasperd Oct 11 '15 at 20:44
  • You should be fine, particularly for RAID-1 it has been around for a while. If in doubt you can test it http://unix.stackexchange.com/a/85880/30851 – frostschutz Oct 11 '15 at 21:07
  • @frostschutz Thanks. I'll take a closer look on that link tomorrow. – kasperd Oct 11 '15 at 21:38
  • @kasperd, yes, obviously it needs to not already have been used.. of course, it is easy enough to trim the unused space one time, or wipe the whole drive before you set it up with an hdparm secure erase. – psusi Oct 12 '15 at 02:12
  • @psusi hdparm has options --trim-sector-ranges, --security-erase, and --security-erase-enhanced. The man page says all of them are dangerous, but it doesn't say clearly what is so dangerous about them. A TRIM command on the entire drive effectively erasing all data from the drive is fine for me at this point. But the man page doesn't make it clear if that's the only reason they are flagged as dangerous. --trim-sector-ranges sounds like the correct argument for me to use. – kasperd Oct 12 '15 at 08:53
  • @kasperd: blkdiscard is much easier than hdparm for trimming entire block devices, but it's a relatively new command that may not yet be available for long-term-stable distros. Even so, you could run it from a current Ubuntu or SystemRescueCD. – frostschutz Oct 12 '15 at 16:30
  • @kasperd, they are dangerous because they destroy data, and so you need to be very careful that you want to destroy data, and that the data you are telling it to destroy is in fact, the data you want destroyed, and not something else. – psusi Oct 12 '15 at 17:29
  • @psusi In that case it sounds like it is no more dangerous than the secure erase. One wonders why the warning in the man page had to be so much more verbose for --trim-sector-ranges than for the secure erase commands. If I can figure out who wrote the warning in the first place, I'll ask them what was the reasoning behind the wording of that warning. – kasperd Oct 12 '15 at 19:01
  • @frostschutz Is the difference between blkdiscard and hdparm --trim-sector-ranges just in UI? Or is there a difference in what low-level commands they send to the drive? – kasperd Oct 12 '15 at 19:03
  • @kasperd, with secure erase, one should know that you are about to erase the whole drive, and in order to use it you first have to set and then specify the password. With the trim-sector-ranges, it isn't obvious that if you get it wrong, you can accidentally screw yourself. – psusi Oct 13 '15 at 20:21