Hard drive danger

[johntee]

I've just been converted to uTorrent from BitLord and find it considerably better. However, as with most new software you find area of concern after the event and the following question was recently posted by one of our members on this forum. I was wondering whether there's any need for concern in this area, or has the new v1.4 taken care of this issue? Here's the members posting:-

"... The only thing that is stopping me from switching to utorrent completely is this -

"µTorrent may be causing excessive disk thrashing in some few cases and may cause some hard drives to exhibit failure earlier than they otherwise would. This issue is considered top priority and will be alleviated in the next builds. It would be wise te refrain from using µTorrent intensively until that time"

Cheerz once again,

johntee

[johntee]

Hi guys,

It appears my legitimate concerns about uTorrent have ruffled the mighty administrators wings in my previous post on uTorrent sending emails. Whilst the helping member "Boo" helped answer my question "FIRON" replied such:-

"Just use ethereal and inspect the packet data if you're so worried. In any case, it's legitimate traffic. Please, do read the FAQ and search before cluttering the forums with useless threads" TOPIC CLOSED.

I've always found that diplomacy is the finest way to achieve and encourage interactivity amonst peers so ALL can learn progressively. I believe that FIRON must be one of those people who was born from the womb on Tuesday and was riding a Harley Davidson on Wednesday................... FIRON, can you remember how you started or does your conceited patronising attitude forbid that?

I goes without saying that this forum is a thing of the past in my books......... goodbye to all good members, you'll need all the help you can get from a 'sore-headed' administrator like FIRON.

[Firon]

That's just a bunch of lies. Also, torrents don't cause enough wear on a drive to reduce its lifespan.

In the few rare cases where thrashing happens (because of disk overload), µT auto-throttles itself back down until it can catch up. In any case, you can compensate by raising diskio.write_queue_size

Also, the betas behave much better than 1.4 stable

And you should expect to get your threads closed when you can't even read the FAQ, let alone search if someone already made a thread about your problem. It's in the rules, and it's in the message when making a new topic. No one's fault but your own for not reading them. Your concern was legitimate, but you should try READING next time. Documentation and rules exist for a reason.

If you'd like to leave even though you were at fault and got your just desserts, suit yourself.

[1c3d0g]

johntee, when you have to deal with hundreds of paranoid people like you every day, you'll be just as swift and decisive as Firon must be to keep the forums running, free from useless clutter. :/

[DonGato]

None can bitch for not reading the documentation or not using the search, what they should do is say sorry and keep going. Almost 50% of support request are already handled in eMule Plus FAQ, but anyway it's today that people ask the same thing it was asked 20 times before. Not taking in account the usage of search that seems to be something so difficult for people to understand. :wink:

Admins should keep the forum clean and sometimes might look like stupid pricks, but bear in mind they have to put with a lot of rude and inconsiderate people every day. It's a hard task.

About disk trashing, is that problematic?

How regularly can happen?

Why is different from other p2p clients?

[bleh]

Yes, that's also a valid question raised by DonGato (hah, love that name btw):

How is µtorrent compared to other clients? and does µtorrent perhaps behave BETTER in that regard aswell? (For all we know, µTorrent might be friendlier on the harddrive simply because of it's grand mission to be as efficient as possible!)

But, Johntee, you really put your foot in this one alright!

Anyways, if you don't believe the FAQ, do try using ethereal to check what gets

sent and what doesn't.

(it's pretty handy for checking other things aswell)

[Firon]

Well, µTorrent's caching (by default) is really not as efficient as other clients, and ludde knows that it needs work still. But for most users, it's really just the same with every client. For those that do have issues, the write queue and read cache are configurable for a reason.

[Ratti3]

If people are really worried about their harddrives failing because of a few extra clicks I suggest they invest in enterprise grade scsi hdd's.

[1c3d0g]

Agreed. A failure in a quad Raid-1 array is damn near infuckingpossible to happen... :/

[Mikademus]

As I understand it this was in fact a very serious issue in the early (< v1.2?) releases of µTorrent, which lacked caching altogether. Thus, at megabit speeds the heads were seeking constantly, and this breaks down even modern units over the course of a night. One user reported this very thing, that µTorrent caused physical breakdown of his drive by r/w seek trashing.

With the implementation of a write cache this (potential) problem ceased for most users, though high upload rates on multiple torrents could still maul the disk bad. Now a read buffer seems implemented and --if functioning well-- should patch that wear and tear risk factor too.

However, a developer or technically savvy person introduced into the inner secrets would need to comment on this, I can't swear on anything. Basically, I simply hope that the read cache does its work, because it is a feature I sorely need.

[Firon]

They actually did have caching, but it wasn't that great, 'cause it was too small by default (1000KB). It was configurable pretty early on though, and that was enough to fix the issues for most people. In reality, the wear from torrents isn't sufficient to kill an HD, unless you have an IBM DeathStar or something. Or if the drive is really old.

And yes, the read cache does work I guess.

[1c3d0g]

Well said, Firon. If indeed the drive failed with a user, it's because that hard disk was already hanging on its last thread... :/

[MoJo]

I must admit my Hard Drive died recently ... could be many reasons, but I suspect it was uTorrent. Not blaming the software though as it became apparent to me early on before even using uTorrent that my HDD was about to die eventually ... guessed that it had 4 months in it turned out to be 3 months. We all know those symptoms of a failing HDD, corrupted/ bad sectors, read/write noises becoming louder, haven't defragged in a long time, slow start-up (booting) and a slow shut down. Ohh well, needed a reason for an upgrade thanks uTorrent .... hehehe

[The Mighty Buzzard]

I just look at dead drives as a source of geek coasters. After the first few times you spill coffee on the platters they hold a cup nicely, before that they're too low on friction.

[DonGato]

Well, if you use any p2p app your disk will be prone to die sooner. I don't see anything wrong with that and it's something you should take in account. Blame disk manufacturers instead of p2p apps.

[DaveBG]

True, too high HDD activity and lots of free RAM unused... On my 30 mBit connectin is runs even slower than Azureus because of non stop HDD read/writes

[DonGato]

Options -> Preferences -> Advanced Settings

# diskio.write_queue_size defaults to -1, which is automatic cache management. µTorrent will automatically adjust the cache size based on your download speed (max measure download speed * 7). If you would like to adjust this value manually, set it 2 to 4 times your maximum download speed in kilobytes, but try to avoid going below 1000, or above 32768 in most situations.

# diskio.coalesce_writes tries to minimize the number of calls to WriteFile. It doesn't have any effect at all on download speed, but it might cause marginally less disk writes (at the expense of more memory / CPU).

# diskio.read_cache_size This sets the size of the read cache (0 = disabled). The value is in KiB.

[splintax]

Agreed. A failure in a quad Raid-1 array is damn near infuckingpossible to happen... :/

yep, but we were talking about regular users, right?

I don't think your average user has a quad RAID-1.

[cool]

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

diskio.read_cache_size to 80000

[Firon]

DaveBG: we've got lots of 100mbit users running just fine

just adjust the two cache values and find what works for you.

[Zygi]

So what recommended value for read cache ??? Also whats wrong with IBM/Hitachi DeskStar series of drives ? I have Deskstar T7K250 250gb do they have some issues ?

PS. In Show Statistics window there is Size of disk queue, when i see write cache size it goes up, but after a moment it change to 1.... is this normal behaviour ?

[Firon]

IBM Deathstar is more like it.

And the value in the statistics page doesn't show the value in KiB, but yeah it's normal.

The recommended value for the read cache is 0 unless you got lots of RAM (more than 1GB), or a really fast connection. In which case, the value is whatever works for you, play with it and see what works.

[Zygi]

I'm not sure i'm safe with Hitachi then i have done search for IBM DeathStar, and this don't look good at all, of course it was in the time of small hdd's but who knows... Whats worse i sometimes hear loud click from disk, and its not my 80GB WD, it could be that click of death from deskstar :/ The drive is almost new 1-2 months, smart status ok, no bads, temps are low.

[1c3d0g]

The "problem-drives" were the 60 GB and 80 GB versions IIRC. Since the takeover Hitachi has done a great job to repair the hard disk's reputation. With hard disks manufacturers, everyone, and I do mean EVERYONE has a different opinion on which one is the most reliable, so I guess I'll just leave it at that.

[Firon]

So the newer DeathStars are no longer DeathStars?