On 24.03.2016 05:11, Vladislav Bolkhovitin wrote: [snip] >>>> +CC: linux-scsi, hch >>>> >>>> Hi SCSI developers, >>>> >>>> I've debugged this further with a v4.5 kernel and full SCSI command >>>> logging enabled on the initiator side. It seems to be a SCSI issue. SCSI >>>> commands succeed but result 8000002 is reported to the upper driver >>>> which seems to fail IO. >>>> >>>> What does result 8000002 mean? >>> >>> It is driver_byte() DID_RESET and status_byte() CHECK_CONDITION (see the >>> corresponding >>> kernel's functions). It sounds like you have timeouts and resets somewhere. >> >> Thanks for the hint! But it is definitely not DID_RESET. It is >> DRIVER_SENSE and CHECK_CONDITION then. The host byte is DID_OK. >> >> If Unit Attention and "Capacity data has changed" is part of a read or a >> write, then the result is the same but this is handled correctly and IO >> is not failed. But with a zero bytes fsync()/flush resulting in >> SYNCHRONIZE_CACHE_16, it fails IO as the sd driver doesn't handle this >> correctly it seems. > > I'm not sure, what is not handled correctly? Zero length SYNCHRONIZE_CACHE is > perfectly > legal, and vdisk_fsync() should never see data_len 0.
The issue is located in the SCSI stack. I think the problem is located in the sd driver. It can't handle zero length SYNCHRONIZE_CACHE together with UA and "Capacity data changed". The race exists to which SCSI command UA is put to. > There should be no race around virt_dev->file_size, because assignments to > 64-bit > integers are atomic, the compiler supposed to align it to 64-bit boundaries > and it's > never assigned to any invalid value. At worst, accesses to it should be > covered by > ACCESS_ONCE(), but I'm not sure it is really needed, so would prefer to keep > it away > from the fast path. Although, probably, vdisk_synchronize_cache() is not too > fast path. SCST is fine. I couldn't break it with my tests. It succeeds the commands but the sd driver fails IO because of the sense data. So discussion should be moved to the linux-scsi list again. I've changed the prefix in the subject from "scst_vdisk" to "sd". [snip] -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
