From: Noveck, Dave (Dave.Noveck@netapp.com)
Date: 06/22/01-12:45:05 PM Z
Message-ID: <8C610D86AF6CD4119C9800B0D0499E33335492@red.nane.netapp.com> From: "Noveck, Dave" <Dave.Noveck@netapp.com> Subject: RE: unix file descriptors and nfsv4 stateids Date: Fri, 22 Jun 2001 10:45:05 -0700 Kendrick Smith wrote: >On Tue, 19 Jun 2001, Noveck, Dave wrote: > > > > Worse, it might succeed and you get the wrong file. I think Mike Eisler > > proposed an open by file handle in the above thread to deal with that issue. > > In wierd cases, there may be further credentials issues since an identity > > change may mean you don't have the right to OPEN the file. Outside NFS-v4, > > you don't have to. This is not an open, it's essentially a DUP. It seems > > wrong to try to shoehorn this into being an OPEN. > > Actually, I've always privately thought that open-by-filehandle would be > a good idea. So far, no client implementation has needed it; they all > implement API's which call for open-by-name. But it doesn't seem > farfetched at all to think that there might one day be clients whose > API's call for open-by-inode or the like (or worse yet, that an unforseen > special case might turn up on an existing client, which makes > open-by-filehandle necessary). Furthermore, open-by-filehandle could > be introduced without changing the on-the-wire protocol at all; one > could just say that length 0 pathnames are allowed in OPEN. As a proof > of concept, I tried implementing this in our Linux server this morning > and found that it only took 8 extra lines of code. I personally like this > idea, since it can be implemented so straightforwardly and avoids a > potential major client issue, but this is not a live-or-die issue at > all for me, since Linux doesn't seem to need it. My only concern about this is with servers that are not as amenable to do doing things by handle. In case it's not obvious, I'm thinking of our old friend NT. On the other hand, such servers do have to deal with the issue for open-reclaim. Maybe adding this function apart from open-reclaim doesn't pose any additional difficulties, but I'd feel better if someone familiar with the NT issues would confirm that. > > It will have to be thought about carefully but my inclination is > > to fix the model if it wrong. I'm not so worried about the replay > > protection issue. I think what we want to do about that is to > > leave the sequence logic with the openowner and let the lockowner > > be different. > > I think that the replay protection has to be associated with the > lockowner, to prevent race conditions where (because of packet > reordering or replay) client & server disagree about which parts > of a file are locked by a particular lockowner. I don't understand the issue your referring to. Can you illustrate with a scenario in which things would break. Thanks.
This archive was generated by hypermail 2.1.2 : 03/04/05-01:48:52 AM Z CST