[nvmewin] regarding slower disk format time
Robles, Raymond C
raymond.c.robles at intel.com
Fri May 22 17:06:52 PDT 2015
Currently, I'm unaware of optimal settings for NVMe devices in general. My take on this is that the value used should be vendor specific. Meaning that each vendor's NVMe drive will have a specific value to that vendor, regardless of a generic formula. Performing the same TRIM command may take longer on some devices than others. I believe this is why the value is defined in a very specific VPD Inquiry page.
Thanks,
Ray
From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of SUMAN PRAKASH B
Sent: Friday, May 22, 2015 12:05 AM
To: nvmewin at lists.openfabrics.org
Subject: [nvmewin] regarding slower disk format time
All,
This is regarding the slower disk format time with the OFA driver compared to Inbox driver on Windows 8.1. Uma Parepalli(skhms) had raised the same concern in February.
In OFA driver, the maximum number of blocks that can be de-allocated, which driver assigns in the MAXIMUM UNMAP LBA COUNT field in Inquiry - Block Limits VPD page is set to 0xFFFF, which is the maximum number of logical blocks for a read or write command. Hence during format, OFA driver gets SCSI UNMAP commands with UNMAP DATA LENGTH set to 0xFFFF at max, always.
The value in MAXIMUM UNMAP LBA COUNT field in Inquiry - Block Limits VPD page has to be set to a higher value based on the logical block size, so that driver will get lesser number of SCSI Unmap commands. We have observed during quick format on a 400GB density disk, OFA driver gets ~6000 Unmap commands.
For ATA devices, following is the formula to calculate the MAXIMIMUM UNMAP LBA COUNT value:
The BLOCK LIMITS VPD page MAXIMUM UNMAP LBA COUNT is calculated by multiplying the value of IDENTIFY DEVICE word 105 with 4194240 (65535 blocks per LBA range × 64 LBAranges per 512-byte block).
We did not find any standard way of calculating the MAXIMUM UNMAP LBA COUNT value for NVMe. The SCSI - NVMe translation spec mentions that this value should be > 0.
We can set the MAXIMUM UNMAP LBA COUNT value to the maximum possible length in logical blocks i.e, 0xFFFF_FFFF. With this, the format performance is as good as MS Inbox driver. But this may not work for bigger density disks as there will be risk of causing a time out while processing a Unmap command for large values of logical blocks.
Does anybody have any idea on how to optimally calculate the MAXIMUM UNMAP LAB COUNT value for NVMe.
Thanks,
Suman
[http://ext.samsung.net/mailcheck/SeenTimeChecker?do=502122e85cbba61a0ce65e18eb501182daf257cfe78672b87d9badbdf7e30042d1afaaba7860cdcd9564217c646641ad61e16949eaa607501b20909a04efd4d2748cfe1d4e847419cf878f9a26ce15a0]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20150523/d70560c5/attachment.html>
More information about the nvmewin
mailing list