On Thu, 2013-06-13 at 21:09 +0200, Carlos E. R. wrote:
On 2013-06-13 18:03, Roger Oberholtzer wrote:
On Thu, 2013-06-13 at 10:18 -0400, Greg Freemyer wrote:
fyi: This is a new call to me and I've never used it, so I have no first hand feedback.
Initial tests look promising. When the call is done, the cache drops by whatever the app has caused to be added. Unlike the brute-force approach I first did, the cache for other activities is not effected.
Let me clarify.
The cache initially grows while calls are made, and when the file is closed, it drops. About to gigs, right? Well that's very good, just what you need.
It does not drop when the file is closed. Only if the file is deleted or the file system umounted (neither of which I can reasonably do IRL), or posix_fadvise(fp, 0, 0, POSIX_FADV_DONTNEED) is called. So I now call posix_fadvise() periodically. I do not fiddle with fdatasync as I do not mind a reasonable bit if buffering. If the cache was really mainly a read cache and not tons of stuff waiting to do to disk (as seems to be implied in various discussions), then I do not understand the occasional >4 second fwrite() delays and, more importantly, why the call to posix_fadvise() helps. That call does not cause a flush. It only arranges that pages that do not contain unique information (in mem and not on disk) are freed. Perhaps I am not meant to understand this mystery :) I am satisfied that I have a solution. I am still not satisfied that the dynamics of the situation are what we think. But life must go on. And testing proceed. Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org