On 8/13/2013 6:16 PM, Doug wrote:
On 08/13/2013 04:27 PM, Brian K. White wrote:
On 8/8/2013 5:42 AM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday, 2013-08-08 at 07:59 +0200, Per Jessen wrote:
/snip/
But writing raw images to device nodes in an exact, reproducible, predictable manner is not an advertised function of cp. So if it worked, it was by happenstance. Even if it worked 500 times on every version of linux available right now, that is still happenstance. All those versions of linux still probably derive their version of cp from the same gnu base, with the only differences being age.
While dd is specifically made to do exactly that. It doesn't just happen to work for that also.
Probably the main difference behind the scenes is the assurance that dd will write one byte after another contiguously, no skipping around to use free blocks wherever they may be.
/snip/
I was recently advised to use rsync to do something like this. I tried it on a test--a portable drive--and it didn't work. Maybe I did it wrong, I don't know. What I want to do is to copy partitions (one at a time) to another drive with a different set of partitions, just a bit bigger. (And numbered differently, leaving out some that will not be used in the future. One reason is that the present drive partitioning scheme has unusable spaces where I cannot expand into them. I want to make a clean partitioning setup on another drive--actually an SSD, in the final cut.
Will DD do that, or will it choke on having partitions of a different size, and different number? (IE., what is now sda8 may become sdb5, and so on, and then when that drive is mounted as the only drive, it will, I hope, be sda5.)
--doug
You can proceed a few different ways. The best way is probably create new empty filesystems manually on the new partitions, then use rsync to copy all your files over to them. The advantage here is that rsync is resumable (if you abort in the middle, it doesn't have to start over from the beginning), and it works for any kind of fs as long as you can mount that fs in linux. Another way is dd the old fs to the new partition, then use whichever utilities are appropriate for the fs type to grow the fs to fill the new space. Not all fs's are growable but the common current linux ones are. At least ext3, ext4, reiser. They don't all use the same command, ie there isn't a growfs command. ext3/4 has resize2fs, reiser has resize_reiserfs, xfs probably has something, btrfs probably has something, etc. This all also assumes you aren't using lvm. This way might work if you had a non-linux fs from some other OS where you can't mount or resize the fs from linux, but you can dd any block of disk bytes, and then maybe the other OS can resize it's own fs itself later. Generally, copying a fs to a larger partition or whole device (no partition table) does not affect the fs at all, it still works fine exactly as before. But it also does not use the extra space. You have to resize the fs to use the extra space. Not all fs types can be resized. Some can be resized but maybe there is no linux utility to do it, or not a safe one anyways. Some can only be grown and never shrunk, some can be grown or shrunk. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org