detailed NOTIFY_DEVICEID4_CHANGE semantics?
2014-09-01 02:03:57 GMT
RFC5661 is very sparse on NOTIFY_DEVICEID4_CHANGE semantics, and the other layout RFCs don't mention it at all. I'm particularly worried about the very imprecise language that talks about outstanding I/O, but does not mention outstanding layouts, which are the objects that refer to deviceids in pNFS: NOTIFY_DEVICEID4_CHANGE A previously provided device-ID-to-device-address mapping has changed and the client uses GETDEVICEINFO to obtain the updated mapping. The notification is encoded in a value of data type notify_deviceid_change4. This data type also contains a boolean field, ndc_immediate, which if TRUE indicates that the change will be enforced immediately, and so the client might not be able to complete any pending I/O to the device ID. If ndc_immediate is FALSE, then for an indefinite time, the client can complete pending I/O. After pending I/O is complete, the client SHOULD get the new device-ID-to-device-address mappings before sending new I/O requests to the storage devices addressed by the device ID. What is a pending I/O in this case? As far as the MDS is concerned I/O operations aren't visible in pNFS, we just have outstanding layouts that can be commited and/or returned. For my block layout client and server implementation I'm interpreting the ndc_immediate = FALSE case in the following way: The client may finish any I/O using outstanding layouts that reference the previously provided device-ID-to-device-address mapping, and SHOULD use GETDEVICEINFO to obtain the updated mapping before requesting new layouts for the previously provided device-ID-to-device-address mapping.(Continue reading)