I’m shopping for a new NVMe SSD drive for my laptop and with the second deciding factor being Linux compatibility, I’d looked up the names of specific drives in the source code of Linux and discovered that their controllers have quirks that have to be worked around.
Now, I figured out more or less how quirks affecting one of the controllers impact its functionality under Linux, but there’s another controller that I have a trouble understanding how disabling the aforementioned command limits the functionality of, if at all; therefore I’d like to ask you all, under what circumstances is the command used by a host and can disabling it lower the performance or power efficiency of an impacted controller/drive?
To be clear, the quirk workaround I’m talking a about is NVME_QUIRK_DISABLE_WRITE_ZEROES.
I am coming at this from a more general angle, so this may not be as applicable.
When a repeated series of inputs is written to a drive, a number of optimisations can be applied. If the user wants a large number of zeros written, the drive’s firmware can use a short cut. Instead of writing those zeros, it can make a note that a number of blocks, at a location, are all zero.
This becomes apparent if one runs fio against the raw block devices versus a software later like LVM. Some operations against some layers will be unreasonably fast. There is a lot of nuance to this.
My read of the quirk is an incompatibility between what Linux expects and the firmware. Enable the quirk only if the dmesg errors are present. Do not expect that the drive has been zeroed. If you want your data secure at disposal of the drive, the then use encryption.
Thanks a lot! This clarifies it for me, and if I understand correctly, it shouldn’t be a concern for me since my laptop isn’t used for data-intensive computing.