> We're already seeing problems just making the buffer cache bigger. > 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 > >> 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.
