dd commmand

[Brian Lee_4]

Is the following case possible?

/dev/vg01/lvol1 => 20GB
This file system contains only 200MB data.

/dev/vg03/lvol3 => 10GB

dd if=/dev/vg01/lvol1 of=/dev/vg03/lvol3 bs=64k

I try to reduce new file system because it doesn't need 20GB space.

[Helen French]

You don't need to use 'dd' command to copy files from two file systems. Instead, use cpio command:

# cd /source_directory
# find . -depth | cpio -pdmv /target_directory.

[Tom Danzig]

No. Use cp instead to copy the file system data only. dd will do the entire LV whether it contains data or not.

[Elmar P. Kolkman · Accepted solution]

I wouldn't do it if I were you. The problem with this is that dd will copy filesystem info too, which is sized for 20 Gb, not 10 Gb.
Since the current need is only 200Mb, I would suggest something like tar or pax.
I don't have the manual of pax by hand, but with tar it would be something like this:
cd ; tar cpmf - . | (cd ; tar xpmf -)

pax has an easier way by using -rw, but I don't know the options to keep permissions etc the same.

cp -rp might even suffice.

[Elmar P. Kolkman]

You could even try to do a 'mv' if you don't need the old copies...

[Alzhy]

Why would you wantr to dd? You could just use cpio or vxdump/vxrestore for that matter.

[Brian Lee_4]

Actually, I tested it and worked fine.
I ran fsck after finishing the task and then could mount the file system.
However, the problem is that there is a read error with one file in the file system.

[A. Clay Stephenson]

You now have a ticking time bomb --- you simply don't know it. When you use dd to copy, you are actually doing a block for block copy. The filesystem although currently using only 200MB is almost certainly sized for 20GB --- whatever the size of the lvol when the filesystem was created. At some point you are going to see massive amounts of corruption. The correct approach would have been to cp, cpio -p, or backup, create a new filesystem and restore.

[Helen French]

Again, if 'fsck' returned any error which is not fixed by fsck, you can reformat that file system with:

# newfs -F fs_name /dev/vgXX/rlvolX

This will erase the file system errors. But if 'dd' or 'stm' returned an I/O error, that's possibly a hardware error, which needs that disk to be replaced.

[A. Clay Stephenson]

The read error is almost certainly an attempt to read what to the filesystem WAS a valid block but is now past the end of the LVOL; again, you have set yourself up for absolute chaos. Fsck doing a log replay (the default) on a vxfs filesystem that has been copied into too small an area will not find this kind of error.

The situation is now like this: You are told to go to 20001 Main Street but we forgot to tell you that we blew up everything past 10000 Main Street.