Creating zpool on NVMe Disks takes forever

[Steven Hartland]

On 20/02/2015 10:20, Tom Evans wrote:
> On Thu, Feb 19, 2015 at 1:33 PM, Steven Hartland
> <killing at 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.
No it will process deletes if the underlying device supports it, not all do.
> On Thu, Feb 19, 2015 at 7:44 PM, Xin Li <delphij at 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.
>
Nope, last time I looked GELI it didn't support DELETE at all, so the 
requests would be ignored.

     Regards
     Steve