On Mon, May 3, 2010 at 3:25 PM, Trond Myklebust <trond.myklebust@xxxxxxxxxx> wrote: > On Mon, 2010-05-03 at 14:56 -0400, J. Bruce Fields wrote: >> On Mon, May 03, 2010 at 12:53:15PM -0400, maillists0@xxxxxxxxx wrote: >> > With NFS4's support for referrals and Kerberos, it seems like the >> > original reasons to prevent re-exporting of an NFS share might no >> > longer exist. With fs-proxy making its way into the mainline kernel >> > and things like cachefilesd, there are also very good reasons to allow >> > it. A proxy server with a persistent cache could give the ability to >> > robustly use shares across a WAN or do failover pairs with no need for >> > more complex replication. Speaking as an end-user, this would be very >> > desirable. >> > >> > I see that others have implemented proxies with user-space NFS, which >> > seems reasonable but not optimal. What is the obstacle to allowing >> > re-exports with the standard nfs implentation? Is it possible at the >> > moment to patch a kernel to make this work? Anyone have experience >> > with it? Any input is appreciated. >> >> It's probably possible, but some kernel hacking would be required. >> Have a look at this old thing from 2006: http://www.usenix.org/event/fast07/tech/full_papers/gulati/gulati_html/nache.html . They claim to have implemented a proxy with only the tools I mentioned above, along with their own modified version of nfs to allow multi-hops. I have a workload of lots of reads/almost no writes, and their approach makes sense. It would be a great feature. Is something missing from that paper that makes it unrealistic? -- 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
