fadvise POSIX_FADV_DONTNEED or POSIX_FADV_NOREUSE

[GoogleCodeExporter]

torrents work as background processes that work on arbitrary files that the 
user might not need to cache anymore (i.e: your favourite distribution isos) 
but, unless you tell the kernel about it, it will try to cache those files, 
droping from page cache the files that the user actually is using.

using POSIX_FADV_DONTNEED or POSIX_FADV_NOREUSE would work:
- POSIX_FADV_DONTNEED: removes the file from cache, wether the user is using 
the file or not. For some people it is considered a bug to drop pages from 
cache that were there before accessing them.
- POSIX_FADV_NOREUSE: tells the kernel that the file can be removed from cache, 
flag that gets invalidated if another process is accessing the same file. This 
is a newer feature and I don't know at what kernel version got implemented, but 
it is kind of new. [1]

I see that you already call to POSIX_FADV_WILLNEED and POSIX_FADV_RANDOM, so I 
don't know if I this has any influence at all in your code.

References:

[1] Linux Kernel Mailing List: http://lwn.net/Articles/449420/
[2] Example patch on rsync for POSIX_FADV_DONTNEED: 
http://tobi.oetiker.ch/patches/rsync-3.0.9-2-fadvise.patch

Thank you

Original issue reported on code.google.com by francesc...@gmail.com on 19 May 2012 at 8:55

[GoogleCodeExporter]

what are you suggesting exactly? that all files libtorrent opens should be 
marked as dont-need when they're closed?

It's not obvious that it would solve your problem. There's already support to 
open files in unbuffered mode if you don't want them to ever make it into the 
system disk cache.

Original comment by arvid.no...@gmail.com on 19 May 2012 at 9:06

[GoogleCodeExporter]

Well, unbufered option is not available in qbittorrent. Maybe it is set as 
default, but this is out of this topic.

Thank you for your answer.

Original comment by francesc...@gmail.com on 19 May 2012 at 9:50

[GoogleCodeExporter]

libtorrent seems to use O_DIRECT for unbuffered access. This appears to be not 
recommended at all.[1][2] I think using fadvise here will be the correct way.

[1] http://www.kernel.org/doc/man-pages/online/pages/man2/open.2.html
[2] http://kerneltrap.org/node/7563

Original comment by saurabhg...@gmail.com on 3 Feb 2013 at 11:17

[GoogleCodeExporter]

Right. This is not on by default though. Do you have a use case where you need 
to disable the filesystem cache, and O_DIRECT is suboptimal?

The only case I can think of is the problem where you're writing a lot to a 
very slow drive, clogging up the entire VM subsystem [1]. I believe this is 
best fixed by calling fdatasync() on the file descriptor after each write 
though.

use of O_DIRECT has been removed from future versions of libtorrent, and since 
the feature is disabled by default it doesn't seem to be any harm. Unless of 
course there is a use case where something like it is needed, but I'm not aware 
of any.

[1] http://lwn.net/Articles/467328/

Original comment by arvid.no...@gmail.com on 3 Feb 2013 at 5:31

[GoogleCodeExporter]

I don't have a problem with data being written. Two programs read a lot of 
data. That's deluge and for my lan, dcpp.
 I don't have a ssd, and I find that my dmenu and some other UI programs, which should be responsive, take a lot of time to start up if they haven't been recently started. This is very reproducible. The only explanation here seems to be that seeding from the only two io-intensive programs replaces other stuff from the kernel cache. Rather than implementing caching in every program, I believe its best if I could disable the automatic caching from my p2p programs, and then let the kernel do its task.
dcpp, rather than deluge is the bigger culprit. I was looking at how libtorrent 
solves the problem to see if I can fix it for dcpp.
But I haven't been able to try out O_DIRECT either. Deluge doesn't have that 
option. Before I can ask them to fix that I think a discussion on fadvise here 
could be more effective. As far I understand, fadvise is equally applicable for 
reads as well as writes.

Original comment by saurabhg...@gmail.com on 3 Feb 2013 at 6:18

[GoogleCodeExporter]

I also think that POSIX_FADV_DONTNEED can become a default for data that has 
already been read during seeding, unlike O_DIRECT, which cannot be recommended 
as a default. This will of course depend on the seeding performance that other 
torrent users want from libtorrent.

Original comment by saurabhg...@gmail.com on 3 Feb 2013 at 6:28