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.
>
> Off the top of my head:
>
> - filehandles: you probably can't pass your server's filehandles
> unchanged back to your client. At a minimum you'd want to add
> a header allowing you to distinguish filehandles for the
> different filesystems you export. What if you get a
> filehandle from the server that's already at the protocol's
> maximum size? Are you going to try to maintain your own
> persistent mapping of filehandles, and if so, is it possible
> to do that with reasonable performance?
> - what do you do if your server takes a really long time to
> answer a request? Or stops responding completely?
* If you want to use Kerberos, then how do you proxy an RPCSEC_GSS
session?
* How does the proxy server figure out the real server's export
rules so that it can re-export them?
--
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
