nvme: make NVME_SC_UNWRITTEN_BLOCK a thin-provisioned error

According to the spec NVME_SC_UNWRITTEN_BLOCK signals 'an attempt to read from an LBA range containing a deallocated or unwritten logical block'.
So this is not so much about the medium being faulty, but rather should be classified as a thin-provisioning error and should be mapped onto ENOSPC.

---
 drivers/nvme/host/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 197a6ba9700f..0462b7e281f4 100644
@@ -179,6 +179,7 @@ static blk_status_t nvme_error_status(struct request *req)
 	case NVME_SC_SUCCESS:
 		return BLK_STS_OK;
 	case NVME_SC_CAP_EXCEEDED:
+	case NVME_SC_UNWRITTEN_BLOCK:
 		return BLK_STS_NOSPC;
 	case NVME_SC_LBA_RANGE:
 		return BLK_STS_TARGET;

@@ -190,7 +191,6 @@ static blk_status_t nvme_error_status(struct request *req)
 		return BLK_STS_NOTSUPP;
 	case NVME_SC_WRITE_FAULT:
 	case NVME_SC_READ_ERROR:
-	case NVME_SC_UNWRITTEN_BLOCK:
 	case NVME_SC_ACCESS_DENIED:
 	case NVME_SC_READ_ONLY:
 	case NVME_SC_COMPARE_FAILED:

2.16.2

Use up your available space for the commit log, please :)

Otherwise this looks fine, although we are unlikely to ever hit it given that Linux never sets the DULBE bit, and setting that bit would break all the partition table and fs probing we have.

Ah. So that's related to the DULBE bit; good to know. (Maybe it could be mentioned in the spec together with the definition in status code.)

So we're having two issues here; the one is the misclassification of the status code, and the other one is the array sending us this error even though we didn't enable DULBE.
I'll let them know.

Cheers,

Hannes

Now that SuSE is a NVMe member you can submit clarifications to Fred for the ECN process..