Date: Fri, 20 Feb 2015 10:20:02 +0000 From: Tom Evans <tevans.uk@googlemail.com> Cc: FreeBSD FS <freebsd-fs@freebsd.org> Subject: Re: Creating zpool on NVMe Disks takes forever Message-ID: <CAFHbX1JaicsqkADnkEOQEF6ywaeisqv1jNb5YdWdtnxxfRwvbg@mail.gmail.com> In-Reply-To: <54E63D17.4000006@delphij.net> References: <54E5BB12.3060707@fuckner.net> <54E5CF6E.5030906@multiplay.co.uk> <54E5D574.8020406@fuckner.net> <CAFHbX1JQkgfZwY%2B2MSvQSZNyhBQQCUiwwGF50PTjfuMy_e1kHg@mail.gmail.com> <54E5F19A.3080804@kateley.com> <54E61C18.8070101@fuckner.net> <d961da9deeee016da3228b362e29454d@mailbox.ijs.si> <54E63D17.4000006@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 19, 2015 at 1:33 PM, Steven Hartland <killing@multiplay.co.uk> wrote: > Technically is not TRIM / UNMAP its BIO_DELETE which is translated by the > relevant device driver to the format the device understands. > > For SCSI this can be TRIM, UNMAP, WS or ZERO, for ATA this can be CFA_ERASE > or TRIM and for NVMe this is a Deallocate. > > One reason why it might be slow is I don't see NVMe configuring geom > d_delmaxsize, which if the case will force the "TRIM" to be split into > single sector deallocation requests. So "zfs_trim_on_init" doesn't require TRIM, it simply ensures it has wiped all data regardless of what the device supports. On Thu, Feb 19, 2015 at 7:44 PM, Xin Li <delphij@delphij.net> wrote: > Encrypted GEOM providers does not support TRIM (neither pass-through > nor random initialization) right now, so this doesn't matter, at least > not yet. Given the above, doesn't this mean that encrypted geoms will be erased block by block on init, regardless of whether they can TRIM or not. Cheers Tom
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFHbX1JaicsqkADnkEOQEF6ywaeisqv1jNb5YdWdtnxxfRwvbg>