[OpenAFS-devel] Re: Out of band FetchData/StoreData

[Matt W. Benjamin]

Hi,

As I mentioned to Derrick, you should request a server and perhaps a client capability
flag, perhaps for precisely the experimental protocol which now exists.  Past that, perhaps it would be helpful to redirect this discussion to afs3-stds, if you're interested in getting a short list of real deployment issues the wider community would be concerned about (e.g., security implications, and satisfactory means of assuring no one is accidentally burned).

Matt

----- "Andrew Deason" <adeason@sinenomine.net> wrote:

> On Mon, 26 Mar 2012 16:15:28 -0400
> Derrick Brashear <shadow@gmail.com> wrote:
> 
> > > I am also currently not releasing the code publicly, because the
> > > protocol used in it is a nonstandard extension (although using
> reserved
> > > RPC code points), and I don't want someone running this in a
> public
> > > cell. But am I just being overly cautious and silly about that? I
> have
> > > no problem with code review (though it seems a bit early for that)
> or
> > > people experimenting with it or anything, but I just imagine what
> > > happens if Joe Q Admin sees "here's some code to make afs go
> faster"...
> > 
> > the sort of people to whom it would be useful would be only the
> ones
> > who control their whole environment anyway;
> 
> Well sorta, but... while you need to control the server and client
> for
> it to make a difference, if you install it on client A and fileserver
> B,
> if fileserver B is _also_ open to the outside world (or client A can
> contact the outside world), that seems like a problem.
> 
> > i'd expect packagers to steer clear of it and thus unless someone
> was
> > building their own stuff end to end it wouldn't matter anyway.
> 
> Well... some people do do that :) Less common on Linux, though, I
> suppose, though pulling patches into existing packaging frameworks
> isn't
> hard.
> 
> I also meant to mention that this is all Linux-only at the moment.
> The
> fileserver bits are trivial to port, but I assume the client bits are
> more work (at least, in order to do zero-copy stuff...).
> 
> -- 
> Andrew Deason
> adeason@sinenomine.net
> 
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel

-- 
Matt Benjamin
The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309