System: FreeBSD fearless2 10.0-RELEASE-p7 FreeBSD 10.0-RELEASE-p7 #0: Wed Jul 9 12:19:19 EDT 2014 root@fearless2:/usr/obj/usr/src/sys/CAMDEBUG amd64 I have an IBM server configured with 400GB SAS SSDs on which I'm trying to create a ZFS pool. # zpool create tank da1 da2 da3 da4 By default, ZFS will trim/unmap the drive when configuring but the UNMAP command takes 78s to complete, longer than kern.cam.da.default_timeout (60). I get timeouts and it tries to resubmit but will never finish: Jul 9 12:40:06 fearless2 kernel: (da1:mps0:0:3:0): UNMAP. CDB: 42 00 00 00 00 00 00 00 18 00 Jul 9 12:41:06 fearless2 kernel: (da1:mps0:0:3:0): UNMAP. CDB: 42 00 00 00 00 00 00 00 18 00 length 24 SMID 623 command timeout cm 0xfffffe00010c11b0 ccb 0xfffff80028931000 Jul 9 12:41:06 fearless2 kernel: (noperiph:mps0:0:4294967295:0): SMID 1 Aborting command 0xfffffe00010c11b0 Jul 9 12:41:07 fearless2 kernel: (da1:mps0:0:3:0): UNMAP. CDB: 42 00 00 00 00 00 00 00 18 00 Jul 9 12:41:07 fearless2 kernel: (da1:mps0:0:3:0): CAM status: Command timeout Increasing kern.cam.da.default_timeout to 90s allows the command to finish and the pool to be created. ZFS should probably UNMAP smaller chunks at a time (4GB?) on initial creation so the command can complete in a timely manner. Or, can it submit the UNMAP request with a much higher than normal timeout? Note that vfs.zfs.vdev.trim_max_bytes doesn't apply here.
the TRIMs are broken down to MAXPHYS Also, the trim support in ZFS will shortly be replaced with the version from upstream which works differently.