 |
What is the use-case you need this for? The whole point of a page cache is to do exactly what it does there. However, the current code is apparently broken, as the check for the filemode is simply implemented wrong. Fixing this would introduce a call to fdatasync() for every file read by the filedaemon. I don't think this is a good idea at all. Either the page cache is clean (and can be released without fdatasync()) or the page cache is unclean and it is definitely not our duty to fdatasync() files we have just been reading. |
|
|
From the bacula mail thread I can understand that they did make the same observations but nevertheless decided that implementing it was an overall better solution: see http://bacula.10910.n7.nabble.com/Support-for-HAVE-POSIX-FADVISE-on-Bacula-Client-tp82345p82361.html What we notice is that RAM memory is completely in use by the page cache. As the files are not evicted from the page cache, they consume RAM after the files were being read by the bareos-fd process. Some processes (on servers with memory intensive processes) are getting swap space as the kernel might think this is more beneficial opposed to evicting entries from the page cache. Mostly this is around the time of the backup process. So I am not arguing against the page cache. Because the “fix” will still use the page cache, but with FADV_DONTNEED it will immediately be released from the page cache. And that is why it's important to us. |
|
|
The problem I see is that the FADV_DONTNEED will also tell the kernel to release data from the page cache that may be in use by other processes. I hope modern kernels are smart enough not to release the cached data in these cases. if you want the fix applied, please prepare a pull request on github with the change so I can discuss it with the other core developers. I think there is a good chance we will accept this. |
|
|
As per request, I've created https://github.com/bareos/bareos/pull/496 |
|
|
Fix committed to bareos master branch with changesetid 13301. |
- Anonymous
