最近在 eBay 上获得了一个 HGST Ultrastar DC SN200（U.2接口）。对方声称这个盘的总上电时间不到12天（原listing写的是6小时-12天），并且做过测试100%保证可以正常工作，发货也很快，从外观上看似乎也没什么问题，于是就去机房把它插到了机器上，结果发现FreeBSD并没有把NVMe识别为disk设备（正常情况下，nvd(4)或nda(4)设备会挂在nvme的namespace上）。
用 smartctl -a 观察，惊喜地发现该设备声称自己是 UCSC-NVMEHW-H1600，所以这是买到了思科固件的NVMe，并且上面没有定义任何 namespace，然后目前的固件版本是 KNCCD111 （思科提供的最新版本是 KNCCD122）。SFH论坛有人指出该旧版固件与戴尔的兼容性存在问题，而最新版本的固件中对其进行了修复，我没有找到相关资料，此处存疑，但在 iDRAC 中确实看到了下面的错误信息：
iDRAC is unable to successfully communicate with the device PCIe SSD in Slot 9 in Bay 1, because of one or more of the following reasons: device is incorrectly seated, iDRAC firmware error, device is in a shutdown state or device firmware error.
二手硬件拿来以后，我通常会刷一轮固件来确保硬件在一个厂商技术支持能够理解的状态而不是某种他们没见过的状态。戴尔的固件都在同一个地方，而思科的固件则需要自行挖掘。在 https://software.cisco.com/download/home 输入这款NVMe配合的思科硬件型号 (UCS C125）可以找到一组固件，下载得到一个可以启动的 iso，然而该 iso 只支持在思科的硬件上启动，而 Dell R640 并不是思科硬件。
FreeBSD 的 nvme(4) 驱动和 nvmecontrol(8) 是支持给 NVMe 设备刷固件的，因此技术上只要把需要的固件文件抽出来就可以直接下载到硬件上。挂载下载得到的 iso 文件，里面有一个名字叫 ucs-c125-huu-container-版本.squashfs 的283MB的文件和一个叫 rootfs.img 的101MB的文件，这是两个 squashfs 文件，在 FreeBSD 上安装 squashfs-tools 之后就可以用 unsquashfs 来从其中提取内容了。
HGST的思科贴牌NVMe的固件在 firmware/Common/HGST__Inc_/Ultrastar_SN200_Series_NVMe_SSD/，这里可以找到一个 KNCCD122.bin ，不过这个文件并不能直接发给设备，而需要先行解密。怎么解密呢？这里就要用到第二个 rootfs.img 中的 usr/sbin/decrypt-file 了，用 strings 可以看到解密的命令行是一条 OpenSSL 命令：
openssl enc -aes-256-cbc -d -md sha256 -pbkdf2 -in %s -out %s.gz -k zfguijkophju@*%1] -nosalt 2>&1
所以解密的方法是：
openssl enc -aes-256-cbc -d -md sha256 -pbkdf2 -in KNCCD122.bin -out KNCCD122.bin.gz -k "zfguijkophju@*%1]" -nosalt
获得的这个 .gz 解压缩之后得到的就是可以刷到设备上的固件了。这款NVMe一共有5个固件槽，其中后4个可写，1号槽是只读的。我们选择2号槽并令其下次激活：
nvmecontrol firmware -s 2 -f KNCCD122.bin -a nvme0
用 nvmecontrol 复位设备，再 identify 就可以观察到固件已经刷新到了 KNCCD122。然而，用 nvmecontrol 依然无法创建 namespace。
最开始我想拿 Debian Live System 去试试看运气，结果发现 Linux 启动后就一直在反复对 NVMe 设备复位，不知道到底是哪里不对。出于无奈，找了一份 Windows 临时安装到这台机器上方便运行 HGST Device Manager。
Windows的磁盘管理器里可以看到这个NVMe设备，但需要初始化，而初始化时提示参数错误，看起来可能还需要做些其他工作。
首先：
hdm scan
结果没找到 NVMe 设备，发现是需要 WDC NVMe 控制器驱动。装上之后 NVMe 设备可以在 hdm 中看到了，hdm 会给设备起类似
@nvme0
这样的别名，这样在操作时可以使用
-a @nvme0
来指定操作的是这个设备。然而在磁盘管理器和设备管理器里都看不到 NVMe 了。
用 hdm get-state 检查发现：
> hdm get-state -a @nvme0 [略] Product Name = Ultrastar SN260 Device Type = NVMe Controller [...] Alias = @nvme0 Device Status = Diagnostic Mode <--- 这是什么鬼？ Thermal Throttling Status = Disabled Life Gauge = 100 System Area Percentage Used = 0 Results for get-state: Operation succeeded.
搜索了一下发现没有可靠的信息来源解释设备怎么会进入 Diagnostic Mode，有许多不同的猜测，从 PCIe 电气兼容性问题到启用了 BIOS 支持，总之没有一个看起来靠谱的结论。但有一点是确定的： hdm 工具+power cycle可以让设备退出这个状态，方法是：
hdm capture-diagnostics -a @nvme0 --file junk_filename --clear-diag-data
Ok 反正来都来了，试了一下发现果然可以了，hdm提供了一个回厂命令：
hdm reset-to-defaults -a @nvme0
数据会全部丢失（大概是会重置namespace，刚买来的二手货这显然是可以接受的风险），果然出现了一个覆盖整个设备的 namespace。
目前还不知道此设备的可靠性如何，个人是有些怀疑的（尤其是厂一下之后SMART数据包括上电时数等等全部归零这事），不过这个盘我打算做cache用，加上它本身声称的寿命，或许问题不大。
厂之后的设备支持了以下四种格式（此前只有第一种 #00）：
LBA Format #00: Data Size: 512 Metadata Size: 0 Performance: Best LBA Format #01: Data Size: 512 Metadata Size: 8 Performance: Good LBA Format #02: Data Size: 4096 Metadata Size: 0 Performance: Best LBA Format #03: Data Size: 4096 Metadata Size: 8 Performance: Better
我选择的是#02。