Trim on gmirrored SSDs is slow and results in inresponsive system
Robert Schulze
rs at bytecamp.net
Wed Mar 4 14:19:46 UTC 2015
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
More information about the freebsd-geom
mailing list