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 <[email protected]> schrieb am 02.08.2017 um 07:09 in Nachricht <dm5pr03mb27297014df96dc01fe849a63fa...@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 _______________________________________________ Users mailing list: [email protected] http://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
