Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a very small and quite old hard drive disk, about 32G.
On to this disk I have copied a largish tar file, about 5G.

When I run md5sum to generate a checksum on this file I repeatedly get different results (on the same machine and the same file). This obviously should not happen.

If I repeat the experiment with a much smaller file, as expected the checksum is the same each time. I can only assume that because the large file is spanning most of the disk, and it is an old drive, I am experiencing a lot of read errors on the hard drive - and it needs replacing? Could there be any other good reason for this? Something I can do to fix the problem other than buying a new disk?

Update: sha1sum also produces inconsistent results.

share|improve this question
This file isn't /dev/random, right? :D – Kevin M Jul 7 '09 at 12:26
No! BTW - this is on a linux (debian) machine. – Joel Jul 7 '09 at 12:28
DO NOT HESITATE. Replace this drive immediately! – kmarsh Jul 7 '09 at 12:31
Browsing thru the questions this morning and coming upon this gave me a chuckle. The title reads something like "Smoke is pouring out of the windows of my house. Do you think I should do something?" I hate to make light of someone else's misfortune, but it just struck me as funny. I'm sick, I guess. – Evan Anderson Jul 7 '09 at 13:13
Yes, it's a crappy machine. I think it was stored outside for a while too. I can see rust on it. Infact - I'm always a little scared to touch it incase I get an electric shock. – Joel Jul 7 '09 at 13:23
up vote 5 down vote accepted

It may be worth running fsck (or the equivalent for whatever filesystem you're using) to fix disk errors. But, it could be the last thing this drive does if it's on its last leg.

share|improve this answer
going for it - running fsck.... – Joel Jul 7 '09 at 12:35
actually seems to have fixed it! – Joel Jul 7 '09 at 16:38
You should still replace the drive ASAP. – SilentW Jul 7 '09 at 18:29
He did say it was an small, old drive. But, if it were worth keeping you can check out Spinrite to do an analysis and repair. It can tell you how damaged the drive is. – spoulson Jul 7 '09 at 18:49

The only likely reasons are bad disk or bad RAM, and as the disk is old and you are not experiencing other issues it is less likely to be the RAM.

It could be a dodgey connector/controller: I once had an IDE->USB adaptor go bad resulting in corrupted transfers even thought the drive was perfectly fine.

share|improve this answer
I, too, have seen the both the bad IDE connector/cable and the dodgy IDE to USB adaptor. Both situations nearly gave me heart attacks, but both were completely benign. – Evan Anderson Jul 7 '09 at 13:14

To be on the safe side I suggest you run memtest86+ over night to make sure that it finds no memory errors.

share|improve this answer

The root cause is that somehow your RAM is getting corrupted. It is probably a bad stick, but sometimes the devices like the video card can corrupt main memory.

Do not fsck until you verify that the memory is safe. Otherwise fsck is likely to corrupt everything.

Pull out drives, put in a known good system, and FSCK there while you fix this system.

share|improve this answer
This is a VERY late answer. Please keep an eye towards the date of the question when providing an answer, and do not rehash areas already covered by others. In this case. the question was posed nearly 3 years ago. I'm sure the problem has resolved itself in one fashion or another long since. – Magellan May 29 '12 at 2:37

Does sha1sum have the same behavior?

I would expect disk read errors before receiving phantom data that alters the hashing process. What platform are you running on?

share|improve this answer
Running on Linux - Debian. – Joel Jul 7 '09 at 12:28

I once had this same problem as well. It turned out to be the hard drive controller on the motherboard.

However, in this case it definitely sounds like a dud hard drive. Hard drives tend to hang onto life by marking sectors bad, transparently, in the background. When sectors finally start to go bad at an OS level the drive ends up expiring very quickly.

share|improve this answer

Since data is different each time it is possible that md5sum is able to read less and less after each run. But failed reads should cause md5sum to quit and report input/output error.

It is very important to backup whatever data you have on this drive and shift to new drive. This drive can fail any time. Do not use this drive for any important work.

share|improve this answer

Is there any process or cron job that is set to automatically add or remove files from this tar file?

I'd also run a disk check. Make sure, as you said, that there aren't any problems with the disk itself.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.