On Tue, Oct 6, 2015 at 11:46 AM, Steven Hartland <kill...@multiplay.co.uk> wrote:
> On 06/10/2015 19:03, Jim Harris wrote: > > > > On Tue, Oct 6, 2015 at 9:42 AM, Steven Hartland < > <kill...@multiplay.co.uk>kill...@multiplay.co.uk> wrote: > >> Also looks like nvme exposes a timeout_period sysctl you could try >> increasing that as it could be too small for a full disk TRIM. >> > >> Under CAM SCSI da support we have a delete_max which limits the max >> single request size for a delete it may be we need something similar for >> nvme as well to prevent this as it should still be chunking the deletes to >> ensure this sort of thing doesn't happen. > > > See attached. Sean - can you try this patch with TRIM re-enabled in ZFS? > > I would be curious if TRIM passes without this patch if you increase the > timeout_period as suggested. > > -Jim > > > Interesting does the nvme spec not provide information from the device as > to what its optimal / max deallocate request size should be like the ATA > spec exposes? > Correct - there is no way for devices to specify a max/optimal deallocate size in NVMe. There is an implicit limit from the 32-bit LBA length in the DSM Range data structure defined by the spec. So this patch is needed anyways to make sure we don't overflow the 32-bit LBA length. Sean's drives are 1.6TB which fits in an unsigned 32-bit value on a 512-byte sector formatted controller, so I don't think that is the problem in Sean's case. -Jim > Regards > Steve > _______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
