[Nottingham] dd and partitions (Re: Very slow dd if=/dev/random)

[Martin]

Paul Sladen wrote:
[...]
> Out-of-interest, what's wrong with using `/dev/zero', which produces a very
> high quality stream of bits, generally uncontaminated by "ones"?

Nothing other than for the sake of experimentation.

I have a 200GB disk in my system temporarily with trashed data, so just 
having a low-level play.


An interesting aside...

On my system, the BIOS recognises the disk as being 200G, but then fails 
to autodetect correctly and fails on one of the SMART commands for it. 
However, Linux seems happy with it. /sbin(?)/fdisk even read the 
corrupted partion tables as far as they went. Mandrake's diskdrake seems 
fine with it.

However, on another system that I flashed the BIOS to support >136GB, 
Win2k trashed the partitions. Also, dd to transfer a backup image onto 
the disk took far longer than expected, suggesting that it wrote beyond 
the size of the backup image.

I've just done a dd to copy my 8GB disk over onto it and it behaved 
exactly as expected, superblock and partitions reported ok by fdisk.


So still wondering whether dd is completely immune from disk drive 
geometries when using /dev/hdg for example...


Also, if I use dd for transferring a partition to an existing partition 
on a __different__ sized hard disk (/dev/hda1 -> /dev/hdgX) for example, 
will the partition tables chain be untouched or overwritten at that point?

(eg: the source hda1 will be copied over but its link to the next 
partion will now be wrong for the destination disk...? Does this work ok 
for primary partions but not logical partitions??)

Cheers,
Martin


-- 
----------------
Martin Lomas
martin@ml1.co.uk
----------------