Creating zpool on NVMe Disks takes forever

[Mark Martinec]

>>>> 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