Date: Thu, 19 Feb 2015 20:26:27 +0100 From: Mark Martinec <Mark.Martinec+freebsd@ijs.si> To: freebsd-fs@freebsd.org Subject: Re: Creating zpool on NVMe Disks takes forever Message-ID: <d961da9deeee016da3228b362e29454d@mailbox.ijs.si> In-Reply-To: <54E61C18.8070101@fuckner.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>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>> On 02/19/2015 12:56 PM, Steven Hartland wrote: >>>>> Disable trim on init: >>>>> sysctl vfs.zfs.vdev.trim_on_init=0 >>>> this fixed it, thx! >>>> >>>> but why does it take >8h to trim 2x 400GB? Or is trimming handled >>>> differently on NVMe than on HDD/SSD? >>> TRIM/UNMAP is simply an SATA/SCSI command that is sent to a device. >>> What the device does when it gets that command is up to the >>> controller >>> and firmware on the device. The default of vfs.zfs.vdev.trim_on_init = 1 can be counterproductive in case of enabling encryption on a device. The FreeBSD handbook for example states: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disks-encrypting.html > 4. Create the New File System > > Next, format the device with the UFS file system and mount it > on an existing mount point: > # dd if=/dev/random of=/dev/da2.eli bs=1m > # newfs /dev/da2.eli > # mount /dev/da2.eli /private So after waiting for hours to populate the disk surface with random bytes, creating a ZFS pool out of it can ditch all the effort and possibly rewrite it with zeros before creating the pool. It should be documented to turn vfs.zfs.vdev.trim_on_init off in the above case. Mark
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d961da9deeee016da3228b362e29454d>