J. Bruce Fields wrote:I just sorta assumed you could fall back to the NFSv4.0 mode of operation, going through the metadata server for all data accesses. But look at that choice in practice: you can either ditch pNFS completely, or use a proprietary solution. The market incentives are CLEARLY tilted in favor of makers of proprietary solutions. But it's a poor choice (really little choice at all). Overall, my main concern is that NFSv4.1 is no longer an open architecture solution. The "no-pNFS or proprietary platform" choice merely illustrate one of many negative aspects of this architecture. One of NFS's biggest value propositions is its interoperability. To quote some Wall Street guys, "NFS is like crack. It Just Works. We love it." Now, for the first time in NFS's history (AFAIK), the protocol is no longer completely specified, completely known. No longer a "closed loop." Private layout types mean that it is _highly_ unlikely that any OS or appliance or implementation will be able to claim "full NFS compatibility." And when the proprietary portion of the spec involves something as basic as accessing one's own data, I consider that a fundamental flaw. NFS is no longer completely open. Jeff -
| H. Peter Anvin | Re: [RFC 00/15] x86_64: Optimize percpu accesses |
| Greg Kroah-Hartman | [PATCH 008/196] Chinese: add translation of volatile-considered-harmful.txt |
| Greg KH | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Alex Chiang | [PATCH 1/4] Remove path attribute from sgi_hotplug |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | Re: [GIT]: Networking |
| Eric Dumazet | Re: [PATCH 3/3] Convert the UDP hash lock to RCU |
