Open Atrate opened 2 years ago
My 2c: That stats screen shows the hit buffer ratio reported by libtorrent, rather than any operating system/file system level cache.
I don't think adding OS specific cache support is really a value add feature, as it would require adding specific code for every file-system type under Linux and specific integration with MacOS and Windows for not very much value add, given that the OS or file-system level cache-hit ratio on a machine that's doing more than just serving torrents, will be driven up or down by other activity.
Fair point. Am I misremembering libtorrent reporting LRU (normal Linux) cache hits?
I can't see any evidence that the WebUI has shown a different value (see example here from 2017): https://github.com/qbittorrent/qBittorrent/blob/1ce71fc63eff386b4cea413fcc60b1e1f54fa3f2/src/webui/www/public/statistics.html
Likewise the stats UI only had that single value since ~2015: https://github.com/qbittorrent/qBittorrent/blob/ff9a281b72ac46f5d2d90e84c380488f6342daf8/src/gui/statsdialog.ui
One thing I noticed is that earlier versions of Libtorrent (earlier that 0.9) used to use a different mechanism for caching that used the term 'ARC' - maybe you had that in mind ? I can only find the ghosts of the code in question over on sourceforge:
https://sourceforge.net/p/libtorrent/mailman/libtorrent-commits/?viewmonth=201202
Might be worth pinging @arvidn on this
qBittorrent & operating system versions
qBittorrent: 4.3.9 x64 Qt: 5.15.2 OS: Arch GNU/Linux, Linux 5.15.10-arch1-1 libtorrent: 1.2.15.0
What is the problem?
In the "statistics" screen, the read cache hit percentage and buffer size are not reported correctly on systems using ARC cache (so on ZFS setups, which are quite popular for NAS). Example: qbt shows read cache hits at 6%, while in other utilities the ARC cache hitrate is closer to 80%.
Steps to reproduce
Additional context
Possibly useful files/commands:
/proc/spl/kstat/zfs/arcstats
arc_summary
Log(s) & preferences file(s)
No response