Date: Tue, 6 Oct 2015 19:46:19 +0100 From: Steven Hartland <killing@multiplay.co.uk> To: Jim Harris <jimharris@freebsd.org>, Sean Kelly <smkelly@smkelly.org> Cc: FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org> Subject: Re: Dell NVMe issues Message-ID: <561416FB.1050802@multiplay.co.uk> In-Reply-To: <CAJP=Hc9-oQnk2r48OBXVCQbMDn0URDMDb80a0i0XvUDPuuLkrA@mail.gmail.com> References: <BC5F191D-FEB2-4ADC-9D6B-240C80B2301C@smkelly.org> <5613FA02.2080205@multiplay.co.uk> <CAJP=Hc9-oQnk2r48OBXVCQbMDn0URDMDb80a0i0XvUDPuuLkrA@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
On 06/10/2015 19:03, Jim Harris wrote:
>
>
> On Tue, Oct 6, 2015 at 9:42 AM, Steven Hartland
> <killing@multiplay.co.uk <mailto:killing@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?
Regards
Steve
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?561416FB.1050802>