About a week ago, this Medion Akoya P4020 D All-in-one PC came in with disk problems. This touch-screen PC is distributed by Aldi and was quite popular a number of years ago. It came with a Western Digital Green 1TB hard disk drive, which on examination was not mounted in its original holder. This meant that the disk could flop around a little to the point, that with some vibration, it could possibly lose Sata contact. Anyway, this is meant to sit vertically so it might not be a problem.
The symptoms were that Windows 7 wanted to do repairs, and this could take all day and all night, which was why it came to me. The first thing I usually do, when faced with an unknown disk drive condition, is to make a copy of the data, whatever is readable that is. I connected the disk to my Ubuntu bench test machine and connected a spare 1TB disk as well. I could have copied the WD disk image to my network storage, but would then be faced with copying it back to another 1TB disk if the WD disk was the problem, so decided to short circuit this process by copying to the spare disk.
The WD disk was showing up as /dev/sdb and my spare Hitachi 1TB disk was /dev/sdc. I used the following command to copy the disks:
dd if=/dev/sdb of=/dev/sdc conv=noerror,sync 2>&1 | tee wdcopy.txt
What this command does is to copy from sdb to sdc, i.e. WD to Hitachi, without stopping for errors, but include blank sectors for error sectors, and the last bit 2>&1 is to send the error output to standard output, where tee will display to the screen and write it out to a file “wdcopy.txt”. I do this now because I have found a number of times where I wanted to know how many errors there were.
In due course, this copy finished – because I didn’t specify a block size, it would default to a single sector block size, which will take a longer time. At completion, the last few lines displayed was:
1953512851+12317 records in
1953525168+0 records out
1000204886016 bytes (1.0 TB) copied, 107443 s, 9.3 MB/s
12,317 bad sectors – and took nearly 30 hours. That does not look good for the WD disk drive, so proceeded to boot the Medion PC with my Hitachi disk. After choosing to start Windows normally, I was able to get to a login screen and duly entered the password, or tried to. The password I was provided did not work, so I tried a few combinations of that password, and was able to get in. Suffice to say that it was a different double digit.
Because of all of those bad sectors, once in the operating system, I tried to do a disk check, which it couldn’t do but could schedule it to be done on boot up – which I chose. On restart, an error came up that it could not perform the disk check due to an error. Logging on again, and restarting came up with the same disk check error.
What is going on? It seems that others have encountered this problem, so the resolution was to boot into Advanced Settings, then I went to a command prompt and ran the “chkdsk /r /f D:” from there.
This took a number of hours, but eventually it completed after fixing a number of errors, actually more than a few. As you can see from the photos, one of the complaints about this PC is that the screen is very glossy and we get lots of reflections that is very distracting. I ran the startup repair as well, but no problems were found. After that a reboot and it was fine, no more disk check on startup.
I contacted the person who brought this machine to me and he said that the customer would be fine with using a second hand disk drive, instead of a new one – so this works for me, as I have a number of spare drives of 1TB capacity sitting around idle. So now this machine is repaired!. I did pad some bubblewrap into the hard disk compartment to stop the disk drive moving around until the owner can find the original mounting frame.
So, what do I do now with the WD disk? Since I have copied the disk already and it is functioning fine in the machine, I decided to run some diagnostics on the disk drive. The WD diags wouldn’t give me anything meaningful, since the quick test that was supposed to take a few minutes kept going and going, so I decided to run the extended test. This completed after many many hours but again didn’t give much result. I decided that the best way was to do a “write zero” to the disk, which is effectively a low level format of the disk using the WD diagnostics. After another many many hours – I don’t stay and look at it, I just come back every few hours to check if it had completed, until it finished.
This is the screen after the diags finished writing. It gives the Smart statistics which shows that the attribute 5, Re-allocated Sector Count normalized value of 75 is below the failure threshold of 140, meaning that the disk is failing. Ok, I decided to actually copy the Hitachi disk back to the WD disk. By doing this, I would also check the raw value of this attribute to see whether this continues to increase. This time, I would speed up the copying by choosing a block size of 10MB:
dd if=/dev/sdc of=/dev/sdb conv=noerror,sync bs=10M 2>&1 | tee hit-to-wd.txt
The raw value of the attribute 5 was 997 – which I obtained from the “smartctl -A /dev/sdb” command. After about 4 hours, the copying was completed, then I check and see that the attribute 5 raw value is now 1056. This meant that during the copying, a further 59 sectors needed to be relocated to spare sectors. A disk drive does not have an infinite number of spare sectors and eventually these will run out. It also means that this disk drive can no longer be relied upon to keep any data. Also this attribute means that the disk surface where the data is stored is deteriorating. Anyway, if the customer wants his original disk back, he is welcome to it, otherwise I keep it on the shelf in case another WD10EARS disk has failing electronics, which would require a donor disk.