[ClusterLabs] Antw: DRBD and SSD TRIM - Slow!

[Ulrich Windl]

Hi!

I know little about trim operations, but you could try one of these:

1) iotop to see whether some I/O is done during trimming (assuming trimming itself is not considered to be I/O)

2) Try blocktrace on the affected devices to see what's going on. It's hard to set up and to extract the info you are looking for, but it provides deep insights

3) Watch /sys/block/$BDEV/stat for performance statistics. I don't know how well DRBD supports these, however (e.g. MDRAID shows no wait times and no busy operations, while a multipath map has it all).

Regards,
Ulrich

>>> Eric Robinson <eric.robinson at psmnv.com> schrieb am 02.08.2017 um 07:09 in
Nachricht
<DM5PR03MB27297014DF96DC01FE849A63FAB00 at DM5PR03MB2729.namprd03.prod.outlook.com>

> Does anyone know why trimming a filesystem mounted on a DRBD volume takes so 
> long? I mean like three days to trim a 1.2TB filesystem.
> 
> Here are some pertinent details:
> 
> OS: SLES 12 SP2
> Kernel: 4.4.74-92.29
> Drives: 6 x Samsung SSD 840 Pro 512GB
> RAID: 0 (mdraid)
> DRBD: 9.0.8
> Protocol: C
> Network: Gigabit
> Utilization: 10%
> Latency: < 1ms
> Loss: 0%
> Iperf test: 900 mbits/sec
> 
> When I write to a non-DRBD partition, I get 400MB/sec (bypassing caches).
> When I trim a non-DRBD partition, it completes fast.
> When I write to a DRBD volume, I get 80MB/sec.
> 
> When I trim a DRBD volume, it takes bloody ages!
> 
> --
> Eric Robinson