[Gllug] Extremely strange disk imaging problem.

[general_email at technicalbloke.com]

I often upgrade hard drives for people, the procedure is dead simple...
I image their existing HD to my computer (using gddrescue) then image
that onto the new drive and use gparted to expand their main partition
to use the rest of the space. Sometimes I will stick the original drive
in a caddy and directly copy it to the new drive skipping my computer
altogether which is effectively the same thing. I've never had any
trouble with this procedure until today...

Last night I did the process above from an 80GB hitachi onto a brand new
500GB WD Scorpio Blue and it worked perfectly except that there is NO
free space left over! Ordinarily in gparted (and windows disk
management) I would see 400+ GB of unused space after the existing
partitions but in this case there is none! I've checked on several
computer and both windows and linux and to all intents and purposes this
drive now IS and 80GB drive! Even the BIOS reports it's 78GB!

I tried zeroing the drive with dd if=/dev/zero of=/dev/sde in the hope
that wiping it clean might make it see sense and return to it's former
500GB self but no.

Annoying though this was I was willing to chalk it down to a fluke of
hardware, boxed the drive up and got an RMA number from my suppliers. As
I hadn't gone to the trouble of verifying the drives size before I
started I figured it could just be an 80GB drive had gotten mislabelled
at the factory or something.

Anyway, today I got some more hard drives in the post and repeated the
process, copying that same 80GB image onto a new 320GB WD Scorpio Black
and exactly the same thing happened! Again, after imaging the BIOS shows
the drive is only 78GB! Before that it was correctly detected as 320GB -
I checked and double checked. What on earth is going on here? I'm at my
wits end and I have a customer waiting who I assured that their machine
would definitely be ready today!...


Fdisk output before:

Disk /dev/sde: 320.1 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000


Fdisk output after:

Disk /dev/sde: 78.5 GB, 78518522880 bytes
255 heads, 63 sectors/track, 9546 cylinders, total 153356490 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xe686f016


How can writing data to a disk change the number of blocks available on
it? It makes no sense, grrrrrr :/


Roger.
--
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug