Ken Hornstein wrote:
> One thing I didn't mention was that the reason I started looking at this in
> the first place was that while copying these files into afs I noticed
> some places where it would "pause" for a while; the file on the client
> wouldn't get any bigger, and it would eventually unfreeze and then
> start getting bigger again. The "freeze" seemed to correspond to
> the FetchData RPCs, but maybe that analysis is incorrect.
>
This is probably where the AFS client is storing parts of the file back to the
server. There can only
be so much dirty data in the cache. Once that level is achived, the dirty parts of
the file are written back
to the server. I believe you said the file was larrger than the cache, so you
would definitely trigger this
case.
> >But I agree that we shouldn't be doing the extra RPCs if possible. One
> >problem is that the original hack didn't work once part of the file was
> >written to the server.
>
> Well, if a cache manager came our way that was changed to not do the
> extra RPCs, I'd be willing to run this test again.
I still think you have a different problem. We can restore the original
performance hack. But note that
that will only help until the first write of dirty data to the server occurs.
There are a couple of ways
of fixing that behavior, some more devious than others. And we will probably be
able to do something
about that. But, to reiterate, I seriously think that if you have slow writes,
this is not your problem.
How long does it take to read this same file back from the server (after fs
flush'ing it of course)?
And how does that compare to the write time. The writes should be slower, but
I don't think it will
be a factor of 2 (but then I have been wrong from time to time before ;-).
>
>
> (I one thought about hacking up a version of cp that stored the file
> directly by using AFS calls so I could bypass the cache manager completely;
> I sometimes wonder what kind of performance I'd get out of that).
Probably faster as you would not also be writing the data to the local disk cache
as well.
>
>
> --Ken
