Disk Cache decrease the read and write frequency of your HD

[radir]

What modern OS you have which is more modern than ones I mentioned?

Also don't forget please that writing is only one half of the problem but reading is the other half. Your patch will help on that side too?

The reason i guess others felt need of user-space cache that torrent generated io pattern is reading/writing of many small random data. Which a) in case of writing causes fragmentation that indirectly impacts performance, and b) in both random read/write causes more hdd head positioning -> direct impact on hdd lifetime. Also many random non-sequential io request can impact whole system performance: while system tries to write out all torrent data cannot do too much else. Please read back this thread and #1521 for experience and measurements. I guess only SSD disks and ramdisks handle this type of load more or less effectively.

But if you collect random write requests for example and turn them into sequential request it would effect write performance and hdd lifetime as well. On the other hand, read cache would help not to read from hdd every time (probably the very same piece) if you seed to many users, which a) would speed up seed b) again would help hdd performance and lifetime.

But maybe I am not very convincing pls check http://en.wikipedia.org/wiki/Comparison ... nt_clients Feature II section, and cache note http://en.wikipedia.org/wiki/Comparison ... e-cache-50 . Out of 25 confirmed clients only 4 is not using cache, one of them is transmission. I admit this may be not total ratio but quite representative, is not it.

Again, there should be a reason why others think user-space cache worth it, and I may fail explaining reasons but it seems more people think pro than con.

[jch]

The reason i guess others felt need of user-space cache that torrent generated io pattern is reading/writing of many small random data.

Dear Radir,

Thank you very much for your kind explanation of what purpose a cache serves.

Interesting as your lecture may have been, however, it has nothing to do with the argument at hand, which is not about whether caches are useful in general, but whether a user-space cache is useful in the presence of a well-implemented kernel buffer cache.

As you justly mention, there is basically no locality in BitTorrent's pattern of disk accesses. This implies that any reasonably-sized userspace cache will be smaller than Transmission's working set. I do not understand how a cache smaller than the working set can improve performance.

(Note that this doesn't mean that there aren't minor optimisations that can be made to Transmission's I/O behaviour. In particular, it would be possible to read whole pieces at a time, and to delay writing out until we have a complete piece. However, it is difficult to see how the former may bring any improvement over the patch in #2551. The latter, on the other hand, might be a good idea.)

there should be a reason why others think user-space cache worth it

Either they have hard data, in which case I'd like to see it. Or else they don't have hard data.

--Juliusz

[radir]

pm was sent

[jch]

Okay, I've implemented a simple write cache. The patch is available on

http://trac.transmissionbt.com/ticket/1521

Please let me know if you manage to measure any performance difference.

--Juliusz

[jch]

Okay, I've implemented a simple write cache. The patch is available on

http://trac.transmissionbt.com/ticket/1521

I've updated the patch to work against the current trunk. Please test this patch, and let us know whether it actually does improve performance -- there's no point in adding a performance tweak if it decreases performance.

This is the time to test it -- I will not be refreshing this patch forever.

--Juliusz