On Fri, 2008-07-04 at 17:38 -0400, 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. I've not ever read up on clonezilla, so I don't know if this is a good thought or not. If you can tell clonezilla to just make the partitions and copy the non-LVM stuff, it might then be faster to do a manual dd of the LVM PV because you can specify a large blocksize (bs=xxxxx, I usually do a cyl size as the blocksize) and it might go much faster. WARNING: if you have more than one PV in the volgroup this can be dicey because of the LV records stored on the PVs. I would not recommend it. OTOH, if it is cranking away and you are now free to do other things, you might want to just let it run. Now, I wanted to make you aware of a recent experience I had using a usb external drive. I don't know if it will/does affect you. I moved all my CentOS torrent stuff to a brand new Tosh 80GB external usb drive. Then on CentOS 4.6, I fired up the torrents and started sharing with the world. Nothing else was running. Three consecutive days, the rtorrent screen became unresponsive. The machine was not locked up. But there was a lock in the wait channel for the drive and it could not be broken. None of the kills (HUP, USR1, KILL) would break the lock and kill the process. This is usb 2.x and, again CentOS 4.6. I have no idea of the cause or if it may behave the same in 5.x or if it is unique to rtorrent or the Tosh drive or 4.6. I'm going to try it on 5.2 this P.M. Sleep well! >:-) > <snip sig stuff> HTH -- Bill