On 12/09/14 17:03, David Brown wrote:
On 12/09/14 02:46, Chris Murphy 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.
smartctl --identify=wb /dev/diskX | grep -i trim
Chris Murphy
Would it be possible to change trim/discard commands into write zero
blocks for some SSDs? A number of SSD controllers support transparent
compression, so writing large batches of zeros will result in very small
writes to the actual flash, and the SSD controller will be able to
recycle flash used by the overwritten logical blocks just as if they
were trimmed. Obviously writing zeros will take longer in transfer than
trim commands, but the result on the disk would be similar and it would
be guaranteed deterministic.
I have 6 drives here. 3 Intel 330's and 3 Samsung 830's. The Intel 330s
compress transparently (Sandforce controllers). They also support
deterministic and return 0 on trimmed areas. The Samsungs don't compress
and don't support deterministic or 0 on trimmed areas.
They are in a 6 drive RAID10 and I just put up with the massive mismatch
count. Contrary to what Chris wrote, there is no damage caused by a
repair type of scrub. Depending on the direction it either copies 0's to
the Samsungs or random garbage to the Intels. It simply ends up writing
to all the trimmed areas, so I don't do it.
Frankly if I considered this an issue I'd just go and replace the
Samsungs with something newer, but as it has no practical ramifications
in the real world I'll use them until I either run out of space or I
wear them out.
I certainly don't believe it is worth of any form of special casing in
the block, RAID or filesystem code. Just tell people that if they want
to use SSD's in RAID and get properly working trim then all drives need
to support return deterministic and return 0 on trim.
As it is, I get this once a month :System Events
=-=-=-=-=-=-=
Sep 7 02:12:49 srv mdadm[6341]: RebuildFinished event detected on md
device /dev/md2, component device mismatches found: 7100032 (on raid
level 10)
The machine is on a serious UPS and gets rebooted about twice a year, so
I'm not afraid of unclean shutdowns.
Regards,
Brad
--
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
