On Wed, Mar 25, 2015 at 08:49:19AM -0400, Trond Myklebust wrote: > The reason for the GETDEVICEINFO description in RFC5661 is that you > need some mechanism to allow clients to know when a deviceid is > retired. There is no reasonable alternative to notification that > doesn't cause problems on either the client or the server. > > That said, do note that one valid solution here is to have deviceids > that never expire (i.e. if you need to retire them, then you allocate > a new one). Given that the deviceid is a 128-bit field, such a > solution is 100% practical. That would allow you to say you support > notification, but not have to implement it. Deviceid must never be retired and reused, to quote from 12.2.10.: Once a device ID is deleted by the server, the server MUST NOT reuse the device ID for the same layout type and client ID again. This requirement is feasible because the device ID is 16 bytes long, leaving sufficient room to store a generation number if the server's implementation requires most of the rest of the device ID's content to be reused. This requirement is necessary because otherwise the race conditions between asynchronous notification of device ID addition and deletion would be too difficult to sort out. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
