News | Forum | People | FAQ | Links | Search | Register | Log in
Hardware Thread
Discuss computer hardware here.
Don't know which components to get? Don't know how to spend your upgrade money? Then ask here, and forum regulars will tell you to fuck off in a number of different ways!
First | Previous | Next | Last
OK, Could Be 
 
i have it turned off for that disk, so it's not indexing or anything.
also, i've experienced the type of slow down during indexing before and rhis is a _lot_ slower.
you can't even watch a video because it'll constantly stall waiting for frames. 
 
Is it defragged? How much free space is not the drive?

If the answer to those questions are 'yes' and 'plenty' respectively, then PANIC!! Get new drive, and back that shit up pronto!!!

Or at least that's my gut reaction. 
Not = On 
 
 
yeah, i'm starting to worry a bit. it's not really fragmented, but there's very little space left on it.
still, if these were the problems, then it would always be slow.
I do have a backup, but i wanted to be sure before i go out and get a new one. :) 
 
what do the SMART values say? monitor them for a while to see changes. 
 
thanks for reminding me about that. speedfan shows a few categories as being in the 'watch' level (as opposed to very good or normal......)
so i'm not sure how to really interpret these values.
not much on google about this either. i suppose it varies between manufacturers? 
 
A single look at SMART is useless, you would need to monitor the values. I use Munin. http://i.imgur.com/R2HTl.png 
More HDD Problems :P 
This time on a different disk then my last post.
Been getting a lot of 'bad block' error events alongside long (10-20s) lockups during disk access.

I've backed up all important data on it and am currently running a chkdsk /r (will probably take all day to finish...)

I've read conflicting opinions about this, some say it's just a simple fix of running chkdsk and reallocating those blocks and others say a bad block error is the herald of impending doom and the HDD is bound to fail.

any opinions on the matter? 
Mobo Chipset? 
 
 
bad sectors can be caused by the motherboard? i thought they were physical errors on the drives themselves.

the board is a p8h67-m (revision 3), the hdd is a WD15EARX or WD15EARS (locked in chkdsk so can't check atm) 
Interesting... 
the windows 7 jumplist had stopped working and i see there was a bad cluster in that exact file... weird.

still going... man chkdsk on large hdds take forever. 
 
harddrives are disposable storage, better have backups. badblocks do not mean that complete failure is imminent. they are no definitive sign for anything really. I have some flash memory that had badblocks from the factory. runs without problems for 2 years now.

always assume your media will be unreadable tomorrow. 
 
yes, that's how I feel about hdds these days; I have two seperate backup hdds now.

so far chkdsk has replaced two separate instances of bad clusters on the drive.

badblocks do not mean that complete failure is imminent
the drive is a little over a year old, but does get heavy use. i shall definitely err on the side of caution for this and i'll be picking up a replacement tommorow. 
Run Spinrite On The Drive. 
You will have to acquire a copy if you don't want to pay for it. It's saved me a couple of laptop hard drives. 
Bad Clusters 
If chkdsk has replaced bad clusters, there is almost certainly nothing wrong with the hard drive itself. A bad cluster is simply the DFS ignoring it for use because of (probably) data corruption within those clusters. Remember, clusters are not sectors.

Presumably, chkdsk saved the data from the bad clusters in e.g. file001, file002 etc. If so, the disk can clearly be read. You can open those files and see if you recognise where the data comes from, which may help you understand what happened. Chkdsk will have also made the data space that those clusters occupied re-available to the DFS for normal use i.e. your available space does not continuously reduce through getting bad clusters as long as chkdsk is finding them.

Most common causes are power loss, or otherwise terminating a program in the middle of a file operation, which results in the DFS not 'understanding' the contents of the clusters and losing track of where they fit into the great scheme of things. Because of that, those clusters are not allowed to be overwritten by normal file operations.

Of course always back up your data but if the drive is only one year old, unless it was second hand when you bought it, or it is some obscure Chinese crap, you cannot have exceeded its working life no matter how much use you have given it.

Catastrophic failure is entirely different, is not foreseeable, and is really, really annoying... 
 
well, the actual problem was bad blocks, which, as I understand it, is a physical problem.
chkdsk was reallocating bad clusters which I'm assuming were on the bad blocks (which is the same as bad sectors, which is not the same as bad clusters... at least in my limited understanding).

anyway, being paranoid about loosing data these days, i've already gotten a replacement. i just don't have enough experience with this kind of thing to make a better guess on the matter. 
 
If a hard disk gives me any read errors i just turf it. Not worth any messing around imho. 
 
wow, cloning the drive took forever; must have been almost half a day.

everything seems to work correctly now and i can get back to quake stuffs. ^_^ 
RE: All Looks Fine Except For One Thing 
The 2500K is a monster of a processor (good taste in CPUs BTW), but it is predominantly designed FOR overclocking

You are confused. Intel doesn't design CPUs for 0,001% of their usebase. 
What Did You Use To Clone The Drive? 
I've always wondered what you have to do to do that.

I've got a 10y/o drive at work with all our admin on it, and i wanna replace the drive by cloning it onto a new one. 
Jago 
You are wrong. About the 2500K and 2600K and the new 3###K's not being for overclocking.

I mean have you read some info before crapping on my 'claim', which is public knowledge?

You can buy a core i5 2500 (no K here), and a 2500K, the only difference between the two is that the K one is designed to be overclocked and about $5. You can't change the multiplier on a non-K CPU, but you can on a 'K' one.

I'm not even going to find some links to back my 'claim' up, but good troll BTW. Look at my rant ^ (!) 
 
Semantics, Or What? 
The K options have an unlocked multiplier; the non-K have it locked. But you can change the BCLK on a non-K, so actually, both are "overclockable". So which was designed for what or are they both the same design, with the K versions just having some extra like a heated front windscreen or low profile tyres? Other than that?

Still, think I'll go Ivy Bridge and drop the graphics card (tee, hee, hee). 
MW 
That is true, but it's been proven that because of the way that Intel have designed their architecture, and due to the fact that the FSB is synched with the PCI bus directly, you cannot achieve a stable FSB overclock of more than about 5%. But if you use a 'K' series CPU and a motherboard chipset that supports overclocking in this way, overclocking via the multiplier will achieve results of stable 50% overclocks. Which is a factor of 10 times more than using the FSB.

As per usual, Intel are just 'disabling' the functionality for overclocking in their non-K CPUs rather than adding the functionality into the K series ones.

But the fact remains that the ONLY benefit (ahem) you will get from a K series CPU is the ability to overclock by up to 50% using the multiplier. So the affinity between the two means that Intel have released a range of CPUs which are designed specifically for the overclocker. QED.

Also, the onboard GPU is actually not that bad.
I have an i3 2330 in my laptop with HD3000 graphics, and I can actually run Skyrim on it. With super-low settings. It runs UE3 pretty well, Fallout New Vegas fine, even on med-hi. 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.