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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
