On Apr 10 2007 10:37, Trond Myklebust wrote: > >NFS, OTOH, simply could not work without that requirement, since there >exists no file pointer to tell you where you are in a stream beyond >whatever the server manages to encode inside the opaque cookie+verifier. > >> But the fact of the matter is that if NFS protocols demands that a >> per-directory entry cookie can be uniquely and permanently (including >> across server reboots) identified with a small integer number, it's >> dreaming. Filesystem authors will cheat one way or another, because >> there's nothing else for them to do. > >Few people in the NFS community would disagree that the design of >READDIR sucks (personally, I consider it to be one of the biggest >scalability issues we have). >The problem is that it is extremely hard to come up with an alternative >that doesn't impose new conditions on what filesystems you can support.
I had a thought, but I think it's not quite ripe.. NFS server sends the whole directory contents on NFS client opendir, so that the whole readdir/telldir/seekdir magic can happen on the client only... which would perhaps also enable a cheap telldir/seekdir, and would also give a 'fixed view' when adding/deleting files during readdir. Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
