Re: r249939+ not detecting ata trim
- Original Message - From: matt sendtom...@gmail.com To: freebsd-current@FreeBSD.org Sent: Saturday, April 27, 2013 10:00 PM Subject: r249939+ not detecting ata trim I had been updating/porting Steve Hartland's patches for zfs trim on mps for 8.3 stable. Trim was working fine for me before r249939. When I saw that this functionality was being added to current, I built world/kernel without the patches. Indeed, many of the commits are quite similar to the updated patch I worked on (patch claims most of it is 'already applied'). HOWEVER, I am not seeing a delete method detected for either of my Samsung 830s, which I did under my updated patch. It looks like scsi ata identify is not working. Are there still outstanding commits to enable this, or is something now a tunable/sysctl I'm missing? Previously it was working: kstat.zfs.misc.zio_trim.bytes: 47546368 kstat.zfs.misc.zio_trim.success: 2618 kstat.zfs.misc.zio_trim.unsupported: 0 kstat.zfs.misc.zio_trim.failed: 0 Current: kstat.zfs.misc.zio_trim.bytes: 0 kstat.zfs.misc.zio_trim.success: 0 kstat.zfs.misc.zio_trim.unsupported: 264 kstat.zfs.misc.zio_trim.failed: 0 kern.cam.da.3.delete_method: NONE kern.cam.da.3.delete_max: 0 kern.cam.da.4.delete_method: NONE kern.cam.da.4.delete_max: 0 I have one patch outstanding (attached) to enable ATA_TRIM support under controllers which don't support UNMAP, I was just finalising testing on this, which I completed this morning; I'm just waiting for approval. If your controller doesn't support UNMAP then this will be the reason, however mps should support this. Could you confirm if previously you where seeing UNMAP as the reported delete_method? 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 postmas...@multiplay.co.uk. cam-enable-trim.patch Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r249939+ not detecting ata trim
- Original Message -
From: Steven Hartland
I had been updating/porting Steve Hartland's patches for zfs trim on mps
for 8.3 stable.
Trim was working fine for me before r249939.
When I saw that this functionality was being added to current, I built
world/kernel without the patches.
Indeed, many of the commits are quite similar to the updated patch I
worked on (patch claims most of it is 'already applied').
HOWEVER, I am not seeing a delete method detected for either of my
Samsung 830s, which I did under my updated patch.
It looks like scsi ata identify is not working.
Are there still outstanding commits to enable this, or is something now
a tunable/sysctl I'm missing?
Previously it was working:
kstat.zfs.misc.zio_trim.bytes: 47546368
kstat.zfs.misc.zio_trim.success: 2618
kstat.zfs.misc.zio_trim.unsupported: 0
kstat.zfs.misc.zio_trim.failed: 0
Current:
kstat.zfs.misc.zio_trim.bytes: 0
kstat.zfs.misc.zio_trim.success: 0
kstat.zfs.misc.zio_trim.unsupported: 264
kstat.zfs.misc.zio_trim.failed: 0
kern.cam.da.3.delete_method: NONE
kern.cam.da.3.delete_max: 0
kern.cam.da.4.delete_method: NONE
kern.cam.da.4.delete_max: 0
I have one patch outstanding (attached) to enable ATA_TRIM support under
controllers which don't support UNMAP, I was just finalising testing on
this, which I completed this morning; I'm just waiting for approval.
If your controller doesn't support UNMAP then this will be the reason,
however mps should support this.
Could you confirm if previously you where seeing UNMAP as the reported
delete_method?
Just tested here on an mps with 8.3 and all seems good without the final
patch; disks are correctly detected as UNMAP support.
I'd be interested in the output from your system after applying the
patch from my previous email plus this:-
--- sys/cam/scsi/scsi_da.c.orig 2013-04-27 23:33:07.413089199 +
+++ sys/cam/scsi/scsi_da.c 2013-04-27 23:10:40.0 +
@@ -198,6 +198,7 @@
};
#define dadeleteflag(softc, delete_method, enable) \
+printf(deleteflag: %s (%d) = %d\n, da_delete_method_names[delete_method],
delete_method, enable); \
if (enable) { \
softc-delete_available |= (1 delete_method);\
} else {\
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 postmas...@multiplay.co.uk.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r249939+ not detecting ata trim
On 04/27/13 15:58, Steven Hartland wrote: If your controller doesn't support UNMAP then this will be the reason, however mps should support this. Could you confirm if previously you where seeing UNMAP as the reported delete_method? 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 postmas...@multiplay.co.uk. I am rebuilding world and kernel with the patches now. Congratulations/thanks on getting all this committed! I'll post the dmesg output from the printf patch afterward. Previously, the delete_method was reported as ATA_TRIM, with a very large delete max. Thanks, Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r249939+ not detecting ata trim
- Original Message - From: matt On 04/27/13 15:58, Steven Hartland wrote: If your controller doesn't support UNMAP then this will be the reason, however mps should support this. Could you confirm if previously you where seeing UNMAP as the reported delete_method? I am rebuilding world and kernel with the patches now. Congratulations/thanks on getting all this committed! I'll post the dmesg output from the printf patch afterward. Previously, the delete_method was reported as ATA_TRIM, with a very large delete max. FYI: Change only requires kernel, world would be identical, which should save you some time. 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 postmas...@multiplay.co.uk. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r249939+ not detecting ata trim
On 04/27/13 18:32, Steven Hartland wrote: FYI: Change only requires kernel, world would be identical, which should save you some time. Regards Steve 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. Thanks, Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r249939+ not detecting ata trim
- 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? I can envisage people wanting to know what delete methods are detected as supported so I've created a new little patch which will print this out from a verbose boot. Its attached if you want to try it, again only a kernel change, I'd be interested in the output you get. You should see something like:- da0: Delete methods: ATA_TRIM(*),UNMAP,WS16 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 postmas...@multiplay.co.uk. cam-scsi-delete-verbose.patch Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
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? I can envisage people wanting to know what delete methods are detected as supported so I've created a new little patch which will print this out from a verbose boot. Its attached if you want to try it, again only a kernel change, I'd be interested in the output you get. You should see something like:- da0: Delete methods: ATA_TRIM(*),UNMAP,WS16 I'll give it a try and send the results. Thanks, Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r249939+ not detecting ata trim
- Original Message - From: matt sendtom...@gmail.com To: Steven Hartland kill...@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 0xfbe0-0xfbe03fff,0xfbd8-0xfbdb 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 0xfbe0 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: 185cScsiTaskFull,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 postmas...@multiplay.co.uk. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r249939+ not detecting ata trim
On 04/27/13 19:13, Steven Hartland wrote: 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 0xfbe0-0xfbe03fff,0xfbd8-0xfbdb 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 0xfbe0 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: 185cScsiTaskFull,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 postmas...@multiplay.co.uk. Here are the delete methods: deleteflag: ATA_TRIM (2) = 1 da4: Delete methods: ATA_TRIM(*) deleteflag: ATA_TRIM (2) = 1 da3: Delete methods: ATA_TRIM(*) deleteflag: ATA_TRIM (2) = 1 Here is a truncated dmesg | fgrep mps mps0: LSI SAS2008 port 0xb000-0xb0ff mem 0xfe83c000-0xfe83,0xfe84-0xfe87 irq 32 at device 0.0 on pci3 mps0: Firmware: 15.00.00.00, Driver: 14.00.00.02-fbsd mps0: IOCCapabilities: 1285cScsiTaskFull,DiagTrace,SnapBuf,EEDP,TransRetry,EventReplay,HostDisc mps0: attempting to allocate 1 MSI-X vectors (15 supported) mps0: using IRQ 263 for MSI-X My firmware is ahead of the driver, and the card itself is an IBM M1015 cross-flashed to what is supposedly identical to a 9210-8i. Thanks, Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r249939+ not detecting ata trim
- Original Message - From: matt sendtom...@gmail.com Here are the delete methods: deleteflag: ATA_TRIM (2) = 1 da4: Delete methods: ATA_TRIM(*) deleteflag: ATA_TRIM (2) = 1 da3: Delete methods: ATA_TRIM(*) deleteflag: ATA_TRIM (2) = 1 Here is a truncated dmesg | fgrep mps mps0: LSI SAS2008 port 0xb000-0xb0ff mem 0xfe83c000-0xfe83,0xfe84-0xfe87 irq 32 at device 0.0 on pci3 mps0: Firmware: 15.00.00.00, Driver: 14.00.00.02-fbsd mps0: IOCCapabilities: 1285cScsiTaskFull,DiagTrace,SnapBuf,EEDP,TransRetry,EventReplay,HostDisc mps0: attempting to allocate 1 MSI-X vectors (15 supported) mps0: using IRQ 263 for MSI-X My firmware is ahead of the driver, and the card itself is an IBM M1015 cross-flashed to what is supposedly identical to a 9210-8i. Hmmm that's unexpected, it could be a FW change, but I'll get an mps box updated to current tomorrow and do some digging. 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 postmas...@multiplay.co.uk. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
