On 1/13/17 11:53 AM, Bart Van Assche wrote:
On Fri, 2017-01-13 at 10:41 -0600, Bryant G. Ly wrote:We're looking into possible issues with AIX disk driver patch where we allow a queue depth > 1 even though NACA isn't supported within LIO. There is a potential issue that we are concerned about, Considering the following: 1. We have a client with 3 virtual disks mapped, with LUN IDs of 1,2, and 3. 2. The user unmaps the disk at LUN ID 3. 3. The user maps a new disk to the client, this new disk gets LUN ID 3. 4. The client doesn't know anything about the change in the disks at this point and sends a bunch of (lets say 3) of Write commands to LUN ID 3. The first write command will get a check condition with a unit attention saying, that the Report LUNs data has changed. But once the UNIT ATTENTION is reported, it is cleared, so the 2nd and 3rd Write commands will get sent on the new disk mapped at LUN ID 3, which is not the one he thinks it is, resulting in data corruption. This is one of the reasons that AIX normally limits the queue depth to 1 if NACA isn't supported. With NACA, the Check condition form the Unit Attention would cause subsequent commands to fail with ACA Active until the client saw the Check condition and sent a clear ACA task management command to clear it. Are you aware of anything in the LIO / Target code that would alleviate this issue? Also take note this general scenario can also happen with Linux Clients in an open stack environment, where this scenario can happen all the time.Hello Bryant, As you know modern initiator operating systems do not scan LUNs sequentially. The LUN to which the REPORT LUNS command is sent has to be present but LUN numbers do not have to be contiguous. Have you considered to leave a LUN unmapped for a while instead of reusing it immediately?
Okay, say we write open stack code, to leave the lun unmapped for x time... a user can still just do it manually, without knowing... I believe if you run the create command without specifying the lun it'll just use whatever is lowest number that is open? -Bryant -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
