On Mon, Feb 07, 2000, Eric Stern wrote:
> > This worries me a little. There is an issue of starvation for readers
> > there. You probably want to tickle out the write data in chunks sized to
> > match your read latency requirements. This also applies to large hits
> > where you do not want one large hit to have a too large impact on the
> > latency of other concurrent hits. Sometimes a few seeks more helps to
> > improve the over all performance.
>
> Yes, true. COSS doesn't handle really large objects too well, thats one of
> the things I'm working on now. The hack I have in place right now is that
> UFS handles large objects (which works out ok). However, I don't want
> to require people to have a UFS store and a COSS store, so I'm working to
> fix that. Large objects will probably be handled much like they are in
> UFS (small chunks read/written). This does result in two code paths, which
> sucks, but its the best I've been able to come up with.
This actually isn't a bad thing you realise. I'm becoming more and more
convinced that a 'general purpose fs' is crap and won't ever be found
UFS is better for large objects, COSS is better for small objects.
Adrian
Received on Mon Feb 07 2000 - 11:04:40 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:12:21 MST