Feature Request: Disk Cache

Suggestions and discussion of future versions
User avatar
Ux64
Seeder
Seeder
Posts: 140
Joined: Wed Nov 14, 2007 5:02 am
Location: System Specialist

Re: Feature Request: Disk Cache

Post by Ux64 »

performance wrote:Cache is meant to reduce # of disk writes but neither of the 2 did a good job at that, it was more of a delay of disk writes than anything else.
Yep. I guess we all know that. I were wondering one thing. In libtorrent documentation they say that using compact allocation is better for cache. But in matter of fact, compact allocation causes more disk access than full allocation. Because compactly allocated pieces need to be moved to right place. In some cases several times. Then moving pieces to right position causes rolling effect. When you need to relocate this piece, you'll need to relocate piece which is occupying space of the piece being relocated, which can cause recursive loop before it's done.

I do understand that if disk cache is really lousy one, then compact allocation might be good idea. Because before you reach half way, you can ad most of pieces directly to the end of file. But after getting to that point, you'll need to relocate and relocate to relocate and so on. Which really doesn't make any sense. I'm quite sure that full allocation is much better in terms of disk access than compact allocation.

Lousy disk cache might not allow seeking in file without flushing. If it supports "append only" buffered write. Does windows support random write staging? I really don't know. Maybe not. It would be clear reason why there is so much disk access when making "random" writes to full allocation files.

How large chunks of data libtorrent or deluge write to disk? 64k? Smaller, larger? There might be option to have kind of cache. I mean simple data buffer which would hold data before it's written out. Like writing only out complete pieces. But in some cases that might take up some memory. Let's say that I'm downloading 50 2 MiB peaces in parallel. Then it would take up 100 megabytes of memory. And in case of crash, I would lose in average half of that.

Writing out only complete pieces would be one solution for those who wish to reduce number of disk writes. And have plenty of disk space and most probably very fast net connection. So what if I lose 50 megabytes of data, it only takes 5 seconds downloading it again using 100 Mbit/s connection. And I got anyway 4 gigs of memory which is mostly "unused" or used for system disk cache anyway. Also when ever some piece is needed for uploading, it would be read completely to memory.
User avatar
Ux64
Seeder
Seeder
Posts: 140
Joined: Wed Nov 14, 2007 5:02 am
Location: System Specialist

Re: Feature Request: Disk Cache

Post by Ux64 »

Here is example of Vista's SUPER DISK IO. ;)

Vista really sucks. Operation should take maximum of 30 seconds, now it's taking 37 minutes. Disk i/o 8,30 KiB/s. Laugh!

This is just what is caused by operating system offering extremely poor disk caching.

Unfortunately it also naturally affects programs running on that platform.
Attachments
Vista super disk io...
Vista super disk io...
vista-performance.png (30 KiB) Viewed 8391 times
User avatar
Izkata
New User
New User
Posts: 3
Joined: Tue Jun 24, 2008 11:31 pm
Contact:

Re: Feature Request: Disk Cache

Post by Izkata »

Playing around with Azureus's cache (I have 2 GB of RAM) has come up with some great results, and is one of the things preventing me from switching to Deluge (as I don't want to touch Vuze)

I typically never go over 1 GB through normal usage, so I figured - why not let Azureus use the rest of it? My current cache size is 360 MB. Just over 1 TV episode or 2 anime episodes. Right after doing this, I noticed all my download speeds are at least twice as fast, usually closer to 3 or 4 times... And this is on Ubuntu. Oh, also, this allows me to seed for as long as I want with zero disk reads.

Hide it in an advanced configuration. Default to something more sane for most people, like 5 or 10 MB, as other clients do. (I think Azureus defaults to 10 MB, and uTorrent to 32 MB). I know I still want it.
garnettxd
New User
New User
Posts: 4
Joined: Mon Sep 24, 2007 10:20 am

Re: Feature Request: Disk Cache

Post by garnettxd »

I dont see any reason why the developers here never implemented any thing about cache. I have once posted suggesting a cache,comes native or in form of a plugin,but over a year past and nothing seem happened. Obviously someone were expecting the same thing.

Deluge wasn't my first BT client, neither the second, nor the third...and every other client I've ever used has a cache setting. After I switched to Linux I found Deluge almost the only choice that complys with clean GUI, full customize, well integration to Gnome desktop, so I suggested a cache for this seemed the only defect. I remember someone said there is no need for this because Linux has it's own cache, I paid attention to the red led on my case and it wasn't flashing all the time, that guy seemed to be right, so I got this out of my mind for a long time.

Today I decided to make full use of my 8GB flash disk by writing it to the fstab and let it work like a download section for ever, ever since the first download begun, the led on flash started blinking, now six hours past it is still blinking without a pause, without a change of rhythm. I can't believe there is any cache belongs whatever. Deluge is writing every little bit to disk. The reason why led of my hdd didn't blink like this could only be a matter of its own 8MB cache. So I figured out writing data to cache of hdd does not cause its led blink. :o I mean...deluge should have a disk cache setting.
User avatar
Ux64
Seeder
Seeder
Posts: 140
Joined: Wed Nov 14, 2007 5:02 am
Location: System Specialist

Re: Feature Request: Disk Cache

Post by Ux64 »

garnettxd wrote:I dont see any reason why the developers here never implemented any thing about cache. I have once posted suggesting a cache,comes native or in form of a plugin,but over a year past and nothing seem happened. Obviously someone were expecting the same thing.
I still have to say that there is no problems what so ever with caching, if operating systems diskcache is working properly. I don't expire any problems with it. Every 5 seconds all uncommitted block are written to disk at once. And no disk activity (usually when downloading) what so ever between those commits.

In generic terms. I personally think it's not smart that every application starts caching data which clearly would be operating systems task. If it's so important to get rid of disk access, why you don't set torrent to use ram drive. Then you got 100% cache for sure. (Unless that ramdisk size is causing additional swapping)
deluge001
Member
Member
Posts: 37
Joined: Fri Sep 12, 2008 8:36 am

Re: Feature Request: Disk Cache

Post by deluge001 »

i totally agree with the devs, that this should not be implemented by apps.
BUT i noticed a lot more disk accesses with deluge under ubuntu than with utorrent under windows.
(and thats with 5 times the memory!)
there is no other (significant) disk i/o, so.. something IS wrong imho.
suggestions for sysctl parameters etc. welcome :)
andar
Top Bloke
Top Bloke
Posts: 1050
Joined: Fri Jun 08, 2007 8:38 pm
Location: Victoria, BC
Contact:

Re: Feature Request: Disk Cache

Post by andar »

Deluge does have a disk cache. It was implemented in libtorrent 0.14 which Deluge 1.x uses.
User avatar
Ux64
Seeder
Seeder
Posts: 140
Joined: Wed Nov 14, 2007 5:02 am
Location: System Specialist

Re: Feature Request: Disk Cache

Post by Ux64 »

deluge001 wrote:i totally agree with the devs, that this should not be implemented by apps.
BUT i noticed a lot more disk accesses with deluge under ubuntu than with utorrent under windows.
(and thats with 5 times the memory!)
there is no other (significant) disk i/o, so.. something IS wrong imho.
suggestions for sysctl parameters etc. welcome :)
Yes, that also might be affected by ubuntus constant root/system volume write cache flushes. As far as I remember maximum time is five seconds without any special tweaking. Other than root/system volume can use much longer flush/comming delays.
Post Reply