[lkml]   [2007]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [nfsv4] RE: Finding hardlinks
    On Fri, 2007-01-05 at 10:28 +0200, Benny Halevy wrote:
    > Trond Myklebust wrote:
    > > Exactly where do you see us violating the close-to-open cache
    > > consistency guarantees?
    > >
    > I haven't seen that. What I did see is cache inconsistency when opening
    > the same file with different file descriptors when the filehandle changes.
    > My testing shows that at least fsync and close fail with EIO when the filehandle
    > changed while there was dirty data in the cache and that's good. Still,
    > not sharing the cache while the file is opened (even on a different file
    > descriptors by the same process) seems impractical.

    Tough. I'm not going to commit to adding support for multiple
    filehandles. The fact is that RFC3530 contains masses of rope with which
    to allow server and client vendors to hang themselves. The fact that the
    protocol claims support for servers that use multiple filehandles per
    inode does not mean it is necessarily a good idea. It adds unnecessary
    code complexity, it screws with server scalability (extra GETATTR calls
    just in order to probe existing filehandles), and it is insufficiently
    well documented in the RFC: SECINFO information is, for instance, given
    out on a per-filehandle basis, does that mean that the server will have
    different security policies? In some places, people haven't even started
    to think about the consequences:

    If GETATTR directed to the two filehandles does not return the
    fileid attribute for both of the handles, then it cannot be
    determined whether the two objects are the same. Therefore,
    operations which depend on that knowledge (e.g., client side data
    caching) cannot be done reliably.

    This implies the combination is legal, but offers no indication as to
    how you would match OPEN/CLOSE requests via different paths. AFAICS you
    would have to do non-cached I/O with no share modes (i.e. NFSv3-style
    "special" stateids). There is no way in hell we will ever support
    non-cached I/O in NFS other than the special case of O_DIRECT.

    ...and no, I'm certainly not interested in "fixing" the RFC on this
    point in any way other than getting this crap dropped from the spec. I
    see no use for it at all.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-01-05 11:33    [W:0.036 / U:0.860 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site