----- Original Message ----- > From: "Trond Myklebust" <trond.myklebust@xxxxxxxxxxxxxxx> > To: "Christoph Hellwig" <hch@xxxxxxxxxxxxx> > Cc: "Tigran Mkrtchyan" <tigran.mkrtchyan@xxxxxxx>, "Linux NFS Mailing List" <linux-nfs@xxxxxxxxxxxxxxx> > Sent: Wednesday, March 25, 2015 1:49:19 PM > Subject: Re: [PATCH 4/4] NFSv4.1: Don't cache deviceids that have no notifications > On Wed, Mar 25, 2015 at 4:55 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: >> On Sun, Mar 22, 2015 at 03:27:32PM -0400, Trond Myklebust wrote: >>> No. The right fix is to make the server support device notifications. >> >> And you instantly thrash performane on any server that doesn't, which >> is why I sent out the errata that no one objected out. I'm happy to >> open this again on the WG list, but the notification scheme is such a >> big hammer that it absolutely isn't worth implementing. Given how >> GETDEVICELIST is specified in 4.1 the original RFC language also is >> inconsistent with itself, so that's not an argument for the old >> behavior. > > 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. I wasn't happy with that change either. But it was easy to add a simple (single bit) hack and lie to client, that server supports notifications. Eventually, if one-time device IDs will be required, client already will do the right thing, which is good. Tigran. > > Trond -- 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
