Robert Moskowitz wrote:
> William L. Maltby wrote:
>> On Fri, 2008-07-04 at 11:41 -0500, Les Mikesell wrote:
>>
>>> <snip>
>>>
>>
>>
>>> Yes, dd is actually pretty slow in wall clock time. Where it wins is
>>> in human time since you just type a short command line and go away,
>>> and it duplicates any setup work you've done in addition too
>>> installing the packages.
>>>
>>
>> But it's not as slow as most think. They just don't take advantage of
>> capabilities, like bs=16384. This makes a *huge* difference in both
>> system overhead and wall clock time.
> Well Clonezilla is busy cloning the drive, but there is a problem here
> cloning to a USB attached drive.
>
> One of the partitions is LVM and since this is a drive clone, including
> the partition table and boot sector, both LVMs (source and target) have
> the same name. So Clonezilla switches to using DD with probably some
> bad parameters. After running an hour, it has only copied 4Gb out of
> 37Gb. Note that the USB port is v1.1.
>
>
> Now actually, I would have perfered renaming the LVM partition and its
> internal ext3 partitions. I even had a naming convention laid out if I
> had do this via Install instead.
If you have any other system on the network that could hold a compressed
image copy you would be better off working with the disks in their
target machines instead of the USB adapter. Clonezilla can use smb,
nfs, or ssh to connect to network storage, so you can use space from
windows or linux. After saving the master image, you would just boot
the clone machines from the CD, connect to the same network location,
and restore to the local drive. That would elminate both the duplicate
LVM problem and the slowness of USB 1.1.
--
Les Mikesell
lesmikesell at gmail.com