On Wed, Mar 25, 2015 at 9:45 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > 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. That doesn't change what I said about the feasibility of working around the notification requirement. -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@xxxxxxxxxxxxxxx -- 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
