Date: Wed, 04 Mar 2015 15:19:43 +0100 From: Robert Schulze <rs@bytecamp.net> To: freebsd-geom@freebsd.org Subject: Re: Trim on gmirrored SSDs is slow and results in inresponsive system Message-ID: <54F7147F.8070206@bytecamp.net> In-Reply-To: <54F707CC.6070105@multiplay.co.uk> References: <54F6FE2E.60303@bytecamp.net> <54F707CC.6070105@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Am 04.03.2015 um 14:25 schrieb Steven Hartland: > Do you have one disk which has really slow TRIM? > please note, it does not depend on the disk, it is related to gmirror. > What's the output for: > camcontrol identify <disk> # camcontrol identify ada0 pass1: <INTEL SSDSC2BB240G4 D2010370> ATA-9 SATA 3.x device pass1: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 512bytes) protocol ATA/ATAPI-9 SATA 3.x device model INTEL SSDSC2BB240G4 firmware revision D2010370 serial number BTWL404203MN240NGN WWN 55cd2e404b586c42 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 4096, offset 0 LBA supported 268435455 sectors LBA48 supported 468862128 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM non-rotating Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags NCQ Queue Management no NCQ Streaming no Receive & Send FPDMA Queued no SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no automatic acoustic management no no media status notification no no power-up in Standby no no write-read-verify no no unload yes yes general purpose logging yes yes free-fall no no Data Set Management (DSM/TRIM) yes DSM - max 512byte blocks yes 4 DSM - deterministic read yes zeroed Host Protected Area (HPA) yes no 468862128/468862128 HPA - Security no > grep quirks /var/run/dmesg.boot results in empty output, same as dmesg|grep quirks > sysctl kern.cam |grep sort_io_queue kern.cam.sort_io_queues: 1 kern.cam.ada.0.sort_io_queue: 0 kern.cam.ada.1.sort_io_queue: 0 kern.cam.da.0.sort_io_queue: -1 > > Also how does gstat -d -p compare between gmirror and none gmirror > installs on the same machine? Deleting on a non-mirrored UFS does not influence the system, because the BIO_DELETE calls are processed extremely fast (~ 1 sec with 1GB file), with a high number of d/s (~ 100k). > Do you see high kernel CPU when the deletes are happening? no. Here are the top system processes after deleting a 5GB file: 0:40 144.87% cam 0:22 77.59% g_mirror var 0:14 62.79% bufdaemon 0:14 0.88% intr 0:13 0.59% geom 0:01 0.00% rand_harvestq 0:00 0.00% kernel with kind regards, Robert Schulze
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54F7147F.8070206>