Date: Sun, 28 Apr 2013 03:13:40 +0100 From: "Steven Hartland" <killing@multiplay.co.uk> To: "matt" <sendtomatt@gmail.com> Cc: freebsd-current@FreeBSD.org Subject: Re: r249939+ not detecting ata trim Message-ID: <5088CCE74E774A0DB87F003BBFB014FD@multiplay.co.uk> References: <517C3C87.1020005@gmail.com> <37582339ED1A4356B6DE6142B2FBCD7B@multiplay.co.uk> <517C7969.4090501@gmail.com> <D77B488FB5184A149D672AB9440612FD@multiplay.co.uk> <517C7E4B.1030501@gmail.com> <33B1A5523E9949278464E92CC6BB722E@multiplay.co.uk> <517C8382.8090404@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message -----
From: "matt" <sendtomatt@gmail.com>
To: "Steven Hartland" <killing@multiplay.co.uk>
Cc: <freebsd-current@FreeBSD.org>
Sent: Sunday, April 28, 2013 3:03 AM
Subject: Re: r249939+ not detecting ata trim
> On 04/27/13 18:51, Steven Hartland wrote:
>> ----- Original Message ----- From: "matt"
>>>> FYI: Change only requires kernel, world would be identical, which
>>>> should save you some time.
>>>
>>> And some untrimmed deletes!
>>>
>>> Thanks, with geom/cam/disk stuff I usually assume that it could affect
>>> userland out of caution.
>>>
>>> BTW...ata identify is working fine, as even before the patch camcontrol
>>> identify indicated trim support.
>>
>> Could you confirm the output you got from the debug as I would have
>> expected to see UNMAP supported on your machine if you mps?
> Output for sysctls
> kern.cam.da.3.delete_method: ATA_TRIM
> kern.cam.da.3.delete_max: 17179607040
> kern.cam.da.3.minimum_cmd_size: 6
> kern.cam.da.3.sort_io_queue: 0
> kern.cam.da.3.error_inject: 0
> kern.cam.da.4.delete_method: ATA_TRIM
> kern.cam.da.4.delete_max: 17179607040
>
> Output for printf
> deleteflag: ATA_TRIM (2) = 1
>
> I thought UNMAP was a SCSI command (for SAS disks), unless we're calling
> it UNMAP and then running ATA's TRIM?
Thats correct, the mps controllers I have here announce UNMAP support for
SATA disks that support TRIM and then do firmware translation on the
commands sent from the OS before passing them to the disks.
This is why I was expecting your controller to still do support delete's
eventhough ATA_TRIM wasn't enabled yet.
I'd be interested to see the details of your controller e.g.
Apr 28 01:36:17 host01 kernel: mps0: <LSI SAS2008> port 0xf000-0xf0ff mem 0xfbe00000-0xfbe03fff,0xfbd80000-0xfbdbffff irq 56 at
device 0.0 on pci129
Apr 28 01:36:17 host01 kernel: mps0: Reserved 0x4000 bytes for rid 0x14 type 3 at 0xfbe00000
Apr 28 01:36:17 host01 kernel: mps0: Firmware: 14.00.00.00, Driver: 14.00.00.01-fbsd
Apr 28 01:36:17 host01 kernel: mps0: IOCCapabilities: 185c<ScsiTaskFull,DiagTrace,SnapBuf,EEDP,TransRetry,IR>
Apr 28 01:36:17 host01 kernel: mps0: attempting to allocate 1 MSI-X vectors (15 supported)
Regards
Steve
================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster@multiplay.co.uk.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5088CCE74E774A0DB87F003BBFB014FD>