On Thu, 11 Sep 2014 18:46:04 -0600 Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > On Sep 11, 2014, at 5:38 PM, Brassow Jonathan <jbrassow@xxxxxxxxxx> wrote: > > > Neil (or anyone else), > > > > I know that trim/discard support was added back in 2012 (commit 9db90880). However, I thought there were still issues regarding what happens when various sync operations occur. I'd like to turn on discard support in dm-raid.c (a oneline patch) if things are in order. I can enable any, all or none depending on your recommendation. (I assume RAID1/10 is easier than the parity RAIDs.) > > If all the controller and drive support it then it should pass through, but there's the problem whether the SSD supports deterministic trim. If it doesn't, a check check > md/sync_action will report mismatches in md/mismatch_cnt; and a repair will probably corrupt the volume. So you can still use trim with a drive that returns non-deterministic results with raid0/1/10, but you can't rely on the result of md/mismatch_cnt and you can't do repair type scrubs. > > For raid5/6, it's a problem to use trim if the drive returns non-deterministically for trimmed blocks. I'd think that in addition to DRAT being supported, it'd need to support DZAT. md raid5/6 will not use trim unless the underlying device reports "discard_zeros_data". That is a Linux internal field name. I don't know exactly that it means in SCSI/SATA/whatever devices. NeilBrown > > smartctl --identify=wb /dev/diskX | grep -i trim > > > Chris Murphy > > -- > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html
Attachment:
signature.asc
Description: PGP signature
