HDD damage?

[fr0y0]

It seems pretty far-fetched, but what are your points on that one? (found it quoted in another forum)

P2P in general requires your computer to commit to frequent reads and writes to the hard drive. This in turn degrades hard drives (think in terms of running defrag all the time).

Azureus jumps out of this problem by having a built-in cache. What the cache does is reduce the number of reads and writes to the hard drive, extending the lifetime of the hard drive. Instead of having to write data every time it gets new data from the network connection, a cache allows Azureus to write data every X or so, X being the size of the cache. A 32MB cache reduces this quite a lot, a 64MB cache reduces it even more. Azureus lets you set the size of the cache. There's the added bonus that Azureus, with its cache, uses less processor time too (meaning "less system resource footprint").

So in essence any BT client without a built-in cache (uTorrent and others) is damaging your hard drive through repeated reads and writes to the drive, whereas any client with a built-in cache is still performing reads and writes to the drive, it just doesn't have to do them as often and thus extends the life of the drive in spite of the P2P efforts to damage the drive.

Say you have a nice office chair, with armrests, that you sit in to use your computer. Take a hammer and whack one armrest ten times quickly over ten seconds. Thats a conventional BT client. Now take the hammer and whack the other armrest once every thirty seconds. Thats Azureus. Continue the once a second whacking on the "conventional BT client" armrest, and the once every thirty seconds whacking on the "Azureus" armrest. Eventually both efforts will result in the armrests falling off the chair, but the "Azureus" armrest will take much more time to fall off than the "conventional BT client" armrest will.

If you were treating both armrests in the "Azureus" fashion, this would give you more time to save up for a new office chair than if you were treating both armrests in the "conventional BT client" fashion.

I hope this analogy is helpful to everyone in deciding which BT client is best for them.

Yes, this does mean that heavy BT users do replace their hard drives more often than other people

I neither want to replace my HDDs, nor use anything else than µTorrent.

[1c3d0g]

The beta builds have a diskio.read_cache_size that you can modify to suit your needs. diskio.write_queue_size also helps in this regard.

[Firon]

Tell them that they're stupid. µTorrent has had a cache for eons.

Also, BT is not very stressing on a HD, believe it or not. Makes very little difference on the life of the drive.

[Ultima]

Hm, then telling fr0y0 to tell those people that they're stupid requires that we know the age of this quote before jumping to conclusions =P

[Firon]

But µTorrent has had a write cache since the beginning...

The age wouldn't matter.

[Ultima]

It wasn't configurable at the beginning... Oh well, fr0y0, just go tell them they're stupid xDD

[fr0y0]

wow, didn't think people would answer so fast... and in a number that big ^^

Well, you say µT has a cache. Is it enabled by default or do I have to determine the size first (diskio.read_cache_size)? Because... right now, I don't know how and where

Thanks for your comments!

[1c3d0g]

1024 = 1 MB

2048 = 2 MB

And so on. Same for the write_queue_size parameter. It's not enabled by default, but as you can see, it's easy enough to change.

[Ultima]

Yep, the write cache is enabled by default. The read cache isn't, since it isn't very effective for the resources it uses anyway. You change them in the Advanced Settings page of the preferences (diskio.read_cache_size for read, diskio.write_queue_size for write).

Sidenote: Hm... just for consistency's sake, maybe ludde should rename diskio.write_queue_size to diskio.write_cache_size?

[fr0y0]

The default value for diskio.write_queue_size seems to be -1. That does mean its unlimited, right?

[Ultima]

That means auto-resize (µTorrent saying "leave it up to meeee to set your write cache size") =P

[fr0y0]

Awesome! Thank you guys!

[Firon]

No, it's still write queue size 'cause it's just that, a queue. it queues up data and then writes it when it gets full or something.

[Kazuaki Shimazaki]

Somehow, I got the feeling that whoever is writing this originally is an Azureus fan, and a uTorrent hater. The post as a whole is misleading.

1) uTorrent has a write queue, as mentioned. BitComet (another popular if private-tracker-despised competitor) also has a write cache.

2) If you look carefully, he tries to infer that Azureus uses less system resources than its competitors (end of Paragraph Two) because of its cache. All I can say is that I pity the guy that gets fooled.

I don't see how a cache would reduce processor cycles - there are actually extra decisions to be made when a cache is used. What I am sure is that system resources includes CPU, RAM and HDD usage and cache is very crudely a tradeoff between extra RAM usage and extra disk access. The bloated cache, when combined with Azureus' bloated structure means lots of extra real RAM usage. Extra RAM usage means less for everyone else, which means an increased reliance on Virtual Memory, which is of course more disk access, as well as more suffering if you are planning on doing anything else while using Azureus (of course, it is really quite impossible to do anything else while you are using Azureus, but sometimes one has to try).

[1c3d0g]

That's why anyone thinking of bringing an Azureus v.s. µTorrent argument (in terms of resource usage) already lost by default. :/

[sektor]

Is there any client that uses MORE system resources than azureus ? )

[Kazuaki Shimazaki]

I think BitSpirit. If BitSpirit is a copy or variation on BitComet, it is a very lousy one.

[cool]

No problems with high noices from my harddrive, quiert like Bitcomet. Has changed

diskio.read_cache_size to 80000

[jmarkson54]

bringing life back to this thread because i feel it's important

Restating what was mentioned here,

- BT does not kill the HD, and makes very little difference on its life

- Frequent writes kill a drive (originally stated by the whomever fr0y0 quoted)

- uTorrent's write cache/queue can be changed. This getting mentioned multiple times implies that the above stated (frequent writes kill drive) is true

- Kazuaki's argument, if I understand correctly, is saying that having a huge cache is more hurtful to the system overall (ram, cpu, AND hdd) than a small cache (hdd only)

This doesn't seem consistent. Does BT really not significantly affect the life of the drive? Would this be because frequent reads/writes don't actually do anything to the life of the drive? I'm not trying to point a finger to anyone saying YOU'RE WRONG, but I feel something's not right here.

Complex evidence is not being requested, I'd be satisfied with a 'yes, torrents reduce drive life significantly' or a 'no, frequent writes do not.' Results from testing would be nice too, but I assume they're not available.

[Firon]

The reads and writes don't really make a difference.

The cache is really to prevent overloads, and help keep up overall system performance, 'cause the disk can't keep up otherwise, since it's so random. BT isn't sequential, so without a cache it would basically be constantly overloaded trying to seek to a different spot for every 16kb chunk.