Date: Tue, 22 May 2018 14:49:56 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 228359] rebuild gmirror + ufs + ssd +trim Message-ID: <bug-228359-3630-eGheIk1EJj@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-228359-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-228359-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D228359 --- Comment #14 from Warner Losh <imp@FreeBSD.org> --- (In reply to Kirk McKusick from comment #12) We'll be plumbing this information up via GEOM soon. However, there's no wa= y to query. The different protocols have different maxes, and devices have diffe= rent sweet spots. The I/O scheduler might be able to measure the latter through different techniques, with a fall back to sysctls to set the maximum size f= or troublesome or awesome devices (down or up) depending... It's not there ye= t. A bigger issue is that we have no async interface to TRIM. This isn't a big d= eal for SATA drives, as most of them can't do NCQ trim (and our support for NCQ trim is limited to ahci), but for NVMe drives it can be a huge difference... --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-228359-3630-eGheIk1EJj>