raid, trim, SSDs, was:Fedora Present and Future

Chris Murphy lists at colorremedies.com
Mon Mar 24 20:11:30 UTC 2014


On Mar 24, 2014, at 12:36 PM, Chris Adams <linux at cmadams.net> wrote:

> Once upon a time, Tom Horsley <horsley1953 at gmail.com> said:
>> On Mon, 24 Mar 2014 11:27:14 -0600
>> Chris Murphy wrote:
>>> Yeah I agree there's too much nervousness about SSD wear issues.
>> 
>> And, of course, hard disks just never fail in comparison, right? :-).
> 
> Of course they do.  The difference is that traditional hard drives don't
> generally have a lifetime measured by number of writes.  Hard drives
> have decades of institutional experience, while SSDs (and their failure
> modes) are new and different.  And, new (and no experience) is always
> "scary".
> 
> With traditional hard drives, failure modes are mitigated by RAID (to
> keep the system running) and backups (to protect the data from drive and
> other types of failure).  With any storage, you should still do backups,
> but for a while RAID setups didn't pass through TRIM commands and so
> were not recommended for SSDs.  

In the realm of "we worry too much about SSD wear" is trim, a.k.a. discard mount option or the use of fstrim command. 

It's actually a lot more important for things like LVM thinp and RAID to be "trimmable" than the underlying physical device. Use of trim on the physical device  is immediately problematic if the device only returns non-deterministic data after trim. It needs to support either DRAT or DZAT, or maybe both (I forget). Otherwise, whether raid1, 5, or 6, the return of non-deterministic garbage results in mismatches that are indistinguishable from massive corruption when doing a regularly scheduled scrub. So yeah, not good.

smartctl --identify=wb /dev/disk0 | grep -i trim

  69     14          0   Deterministic data after trim supported
  69      5          0   Trimmed LBA range(s) returning zeroed data supported

That's on a Samsung 830. I'm not positive, but that looks like neither are supported on this SSD. So that likely means:

1. RAID 0 + trim = OK.
2. RAID 1 + no trim = OK, scrub reliable.
3. RAID 1 + trim = Is redundant but scrub unreliable, will return many mismatches.

An exception is Btrfs raid1 + trim, because it only scrubs allocated data. It doesn't scrub by block.


Chris Murphy



More information about the users mailing list