T. Horsnell wrote: > Yes, but when another application starts up, and needs memory > which has been consumed in UBC, *it* has to wait until sufficient > buffer has been flushed to disk. And since there is no point in > buffering the data in the first place if its not going to be > re-accessed in a short time, that delay could possibly be avoided. This is only in the case where the buffer is holding dirty, written, data that must be flushed. You can use sync utility to force this to happen BTW. > If I write a 20GB file, effectively all my 'spare' memory gets > used for cache. If I then want to run a new application at the > same time, I have to wait while sufficient cache is flushed. > And the writing of that 20GB file may not have benefited > at all by being cached. True enough. But unless your PC is sitting there doing these behaviours alone, normally the buffering only brings benefits generally. If it's possible to add a sync command somewhere along with whatever causes these large file movemnents you can emulate the behaviour you want for this case while retaining the benefits of buffering for the other cases. -Andy
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
