disable_os_cache has no effect

[axet]

Hello!

I'm using qbittorrent 5.0.4 with 'Disk IO read mode' set to 'Disable OS cache' which corresponds to 'disk_io_read_mode=disable_os_cache' libtorrent option. It seems option has no effect on actual file caching.

I run simple test:

1. ran dropcaches
2. ran 'vmtouch -v /torrent_path' == shows 0GB cached
3. ran torrent on /torrent_path folder for 5 mins
4. ran 'vmtouch -v /torrent_path' again and it showing 7GB cached

I expect vmtouch will show 0GB after torrenting, but it seems files still get into system cache I guess O_DIRECT not working? I'm using BTRFS maybe that the case?

[HanabishiRecca]

Libtorrent version? I assume 2.x.

It does not use O_DIRECT actually, it uses O_SYNC. And yes, it does not affect reads at all. So idk why this option still exists. See #3614.

[axet]

libtorrent 2.0.11-1

[axet]

Having O_DIRECT (or any other way skip read buffering) has allows to play modern games and torrenting at the same time.

Modern games using a lot of IO, if game and torrent installed at the same rotational drive, torrent can eat all system read buffer for torrent files. It does not benefit torrenting, but most certainly killing foreground heavy IO applications user experience since apps freezing all the time (not just games, but games mostly).

If heavy game eats 10GB ram for buffering (linux kernel buffer) and works fine, torrent will flush all cache in seconds and replace all buffers with torrent files. As result foreground app start reload all data from harddrive again, caching and freezing badly.

[nyx191]

O_DIRECT may be tricky to use, also silent fallback to buffered I/O is possible if your (file)system was configured in certain way. My suggestion is to use RWF_DONTCACHE which landed in linux 6.14. The only major drawback is fresh kernel requirement, but I think this should be ok for home (btw, arch) users. Also need to check whether this flag is usable across major filesystems. Otherwise, RWF_DONTCACHE should be ideal for this use case, because it uses page cache internally and thus does not require special alignment / block size, just like the usual read/write syscalls. But after job is done, pages are freed immediately, so this looks like more efficient alternative for read() then fadv_dontneed. Still, if we want portability, why not latter?

UPD: Looks like traditional file i/o syscalls are used only for posix-compatible i/o, otherwise libtorrent sticks with mmap

[nyx191]

But anyway, libtorrent does it job by adding MADV_PAGEOUT and MADV_COLD when appropriate, so disable_os_cache should work well.