> We're already seeing problems just making the buffer cache bigger.
quoted text
> You think adding the complexity to optimize access patterns is going
> to make things better?  cp at least has a very good idea of exactly
> what data it's going to need next.  Putting heuristics in the kernel
> is exactly the wrong approach.

While yes, I agree the buffer cache could potentially do better on
read/write ahead, this also
involves the various midlayers and disksort, and potentially being
able to use more than 64K io's

quoted text
>
>> your big buffers is that you are claiming resources even if you have
>> no idea if they are available or not.
>
> What resources?  It uses a small fraction of your RAM.  If a 4 gig
> machine can't spare a couple megs for a file copy, you're in trouble.

Realisticly if cp can be a bit smarter, where's the loss here folks -
even with a smarter buffer cache, userland in this case knows what
it's going to do and doing it smarter is always going to work better -
because the kernel gets more and better hints about what's actually
going on.

To take it to the extreme in the other direction, should I implement
cp as one byte reads and writes, and expect the kernel to optimize my
idiocy away? of course not.  Ted's idea here is not so bad.