[OpenAFS] poor out of cache behavior on writing
Stephen Joyce
stephen@physics.unc.edu
Mon, 17 Feb 2003 20:37:18 -0500 (EST)
On Mon, 17 Feb 2003, Neulinger, Nathan wrote:
> Another possible scenario would be assume bypass until the file has been
> read once. That would cause all initial creates to bypass, but later
> appends/edits would return to normal speed.
How much of AFS' poor performance is due to the CM overhead and how much is
due to the overhead of RX?
I tend to think the performance benefit of this is worth considering. Has
anyone on the list with knowledge of AFS internals taken a look at the
selective cache (table 3) portion of
http://www.citi.umich.edu/techreports/reports/citi-tr-01-3.pdf ? You will,
of course, want to ignore the split path portion of the study for this
discussion.
>
> ------------------------------------------------------------
> Nathan Neulinger EMail: nneul@umr.edu
> University of Missouri - Rolla Phone: (573) 341-4841
> Computing Services Fax: (573) 341-4216
>
>
> > -----Original Message-----
> > From: Derrick J Brashear [mailto:shadow@dementia.org]
> > Sent: Monday, February 17, 2003 5:14 PM
> > To: openafs-info@openafs.org
> > Subject: Re: [OpenAFS] poor out of cache behavior on writing
> >
> >
> > On Mon, 17 Feb 2003, Paul Blackburn wrote:
> >
> > > You probably will get better data transfer from ftp-client
> > => ftp-server
> > > than a distributed filesystem.
> >
> > This, at least, is a protocol. scp is a hack, which is why
> > I'm reluctant
> > to use it.
> >
> > > When it comes to "uploading" large datafiles from machine
> > to machine,
> > > I now prefer using SSH's scp which shows me a progress bar and ETA.
> > >
> > > For most all other tasks, I like AFS which gives me other
> > capabilities
> > > unheard of in NFS.
> >
> > I wonder if we could find a sucker^H^H^H^H^H^Hgrad student to
> > figure out
> > ("guess") when to bypass the cache and when to use it, and
> > incorporate it
> > (at least as an option) in the clients.
> >
> > I know CITI has done cache-bypass stuff, but it used the
> > volume name (I
> > think) as a hint.
> >
> >
> > _______________________________________________
> > OpenAFS-info mailing list
> > OpenAFS-info@openafs.org
> > https://lists.openafs.org/mailman/listinfo/openafs-info
> >
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>