IMHO: dd is better than ufsdump. Any comment ?
Kit-pui Wong
but ufsdump failed to do.
Here're the command that I used. It finished successfully
and the new disk is bootable !
# dd if=/dev/rdsk/c0t0d0s2 of=/dev/rdsk/c0t1d0s2 bs=1024k
# installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c0t1d0s0
# fsck -o p /dev/dsk/c0t1d0s0
I did simialarly with ufsdump but it failed. The file system
(if any) on the new disk couldn't even be mounted !
# ufsdump 0uDf /dev/rdsk/c0t1d0s2 /dev/rdsk/c0t0d0s2
# installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c0t1d0s0
# fsck -o p /dev/dsk/c0t1d0s0
I therefore "feel" that ufsdump is less capable than dd
to mirror a disk. What's your opinion ?
cheers,
KiT
Casper H.S. Dik - Network Security Engineer
86040175@$MAILHOST (Kit-pui Wong) writes:
>dd let me "mirror" a disk to another perfectly
>but ufsdump failed to do.
"dd" is not suitable for mirriroing disks unless both disks
have the exact same gemeotry. (The label is copied too)
># ufsdump 0uDf /dev/rdsk/c0t1d0s2 /dev/rdsk/c0t0d0s2
Yes, that doesn't work. Here you've used the raw disk device as
tape device and the filesystem has been written in ufsdump format.
To clone a filesystem with ufsdump do:
- format - label the new disk just like the old one
- foreach ufs partition:
newfs - make a filesystem on the partition that will hold
a copy
mount the new filesystem
ufsdump 0f - /oldmount | (cd /newmount ;ufsrestore xf -)
- run installboot
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
fish...@my-deja.com
86040175@$MAILHOST (Kit-pui Wong) wrote:
> dd let me "mirror" a disk to another perfectly
> but ufsdump failed to do.
>
> and the new disk is bootable !
>
> # dd if=/dev/rdsk/c0t0d0s2 of=/dev/rdsk/c0t1d0s2 bs=1024k
> # installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk
/dev/rdsk/c0t1d0s0
> # fsck -o p /dev/dsk/c0t1d0s0
>
> I did simialarly with ufsdump but it failed. The file system
> (if any) on the new disk couldn't even be mounted !
>
/dev/rdsk/c0t1d0s0
> # fsck -o p /dev/dsk/c0t1d0s0
>
> I therefore "feel" that ufsdump is less capable than dd
> to mirror a disk. What's your opinion ?
>
> cheers,
> KiT
>
>
Whoa there. You're not using ufsdump correctly! ufsdump creates a dump
file. Basically what you did was write a dump file to the target disk.
You need ufsrestore write the files back into an existing filesystem.
Also you need to use ufsdump on the indivdual slice not s2 (the whole
drive). To do what you want you would need to do something like this:
newfs -F ufs /dev/rdsk/c0t1d0s0
mount /dev/dsk/c0t1d0s1 /mnt
ufsdump -0f - /dev/dsk/c0t0d0s0 | (cd /mnt; ufsrestore rf -)
You would need to do this for every slice that has a file system on it.
dd is great for copying between like drives but when you need to migrate
to a disk with different geometery or perhaps changing to VXFS you need
ufsdump.
--
John
Actual Sun Bug:
4110503 as_setprot heuristic gave my process a wedgie
Sent via Deja.com http://www.deja.com/
Before you buy.
Arthur W Word Jr
Kit-pui Wong wrote:
> dd let me "mirror" a disk to another perfectly
> but ufsdump failed to do.
>
> Here're the command that I used. It finished successfully
> and the new disk is bootable !
>
> # dd if=/dev/rdsk/c0t0d0s2 of=/dev/rdsk/c0t1d0s2 bs=1024k
> # installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c0t1d0s0
> # fsck -o p /dev/dsk/c0t1d0s0
>
> I did simialarly with ufsdump but it failed. The file system
> (if any) on the new disk couldn't even be mounted !
>
> # ufsdump 0uDf /dev/rdsk/c0t1d0s2 /dev/rdsk/c0t0d0s2
> # installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c0t1d0s0
> # fsck -o p /dev/dsk/c0t1d0s0
>
> I therefore "feel" that ufsdump is less capable than dd
> to mirror a disk. What's your opinion ?
>
> cheers,
> KiT
dd is great for mirroring a file. However, ufsdump does have some advantages.
If there are problems with your source file system, dd will not pick them up,
where as ufsdump will. I use the following script to clone file systems.
#!/bin/ksh
for x in c0t0d0s0 c0t0d0s3 c0t0d0s5 c0t0d0s4
do
echo y | newfs /dev/rdsk/$x
done
cd /
mount /dev/dsk/c0t0d0s0 /mnt
ufsdump 0f - / | (cd /mnt ; ufsrestore -rf - )
cd /
umount /mnt
cd /
mount /dev/dsk/c0t0d0s4 /mnt
ufsdump 0f - /usr | (cd /mnt ; ufsrestore -rf - )
cd /
umount /mnt
cd /
mount /dev/dsk/c0t0d0s3 /mnt
ufsdump 0f - /var | (cd /mnt ; ufsrestore -rf - )
cd /
umount /mnt
cd /
mount /dev/dsk/c0t0d0s5 /mnt
ufsdump 0f - /opt | (cd /mnt ; ufsrestore -rf - )
cd /
umount /mnt
installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c0t0d0s0
Write tome
Noone
written on them or not.
I use the following that works great for me:
1. Format drive to create partitions that are similar size (don't have to
exact blocks)
2. newfs each slice
3. cd fromdir; tar xf - . | (cd todir; tar xfBpv -) (look at the man page on
tar. This is directly from there. I may have missed an option). Do this for
each slice.
This works faster than dd or ufsdump. I have only tried ufsdump to a tape
and then restore.
"Kit-pui Wong" <86040175@$MAILHOST> wrote in message
news:8jpl6r$8...@news.cityu.edu.hk...
Rich Teer
> 1. Format drive to create partitions that are similar size (don't have to
> exact blocks)
> 2. newfs each slice
> 3. cd fromdir; tar xf - . | (cd todir; tar xfBpv -) (look at the man page on
> tar. This is directly from there. I may have missed an option). Do this for
> each slice.
>
> This works faster than dd or ufsdump. I have only tried ufsdump to a tape
> and then restore.
Except that tar doesn't understand sparse files, which ufsdump does. E.g.,
you could have a sparse file is, say, 2 GB in size, but only has 50 MB of
data in it (I know, this is an extreme example!). With the tar method, you'll
end up creating a file that actually consumes 2 GB of space; ufsdump will just
take up the original 50 MB. IIRC, tar doesn't handle symbolic links too well
either, but I could be wrong.
--
Rich Teer
NT tries to do almost everything UNIX does, but fails - miserably.
The use of Windoze cripples the mind; its use should, therefore, be
regarded as a criminal offence. (With apologies to Edsger W. Dijkstra)
Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
Markus Gyger
>On Wed, 5 Jul 2000, Noone wrote:
>> 3. cd fromdir; tar xf - . | (cd todir; tar xfBpv -) (look at the man page on
>> tar. This is directly from there. I may have missed an option). Do this for
>> each slice.
> Except that tar doesn't understand sparse files, which ufsdump does. E.g.,
> you could have a sparse file is, say, 2 GB in size, but only has 50 MB of
> data in it (I know, this is an extreme example!). With the tar method, you'll
> end up creating a file that actually consumes 2 GB of space; ufsdump will just
> take up the original 50 MB.
If you compress/gzip/bzip2 the file then it's not that much larger.
You could then use pax to untar the file -- it's slow but creates
sparse files (even if they weren't before -- nice for SunPCi images
without requiring the use of cphd).
Markus
Heiko Klein
option).
And tar doesn't handle ACL's.
You have to use cpio, dd or ufsdump for this purpose.
Heiko Klein
H Richardson
>
> I did simialarly with ufsdump but it failed. The file system
> (if any) on the new disk couldn't even be mounted !
>
> # ufsdump 0uDf /dev/rdsk/c0t1d0s2 /dev/rdsk/c0t0d0s2
> # installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c0t1d0s0
> # fsck -o p /dev/dsk/c0t1d0s0
>
> I therefore "feel" that ufsdump is less capable than dd
> to mirror a disk. What's your opinion ?
>
I find it strange that you would try to mount a dump of a filesystem.
Harvey
hac
>
> On Wed, 5 Jul 2000, Noone wrote:
>
> > exact blocks)
> > 2. newfs each slice
> > tar. This is directly from there. I may have missed an option). Do this for
> > each slice.
> >
> > and then restore.
>
> you could have a sparse file is, say, 2 GB in size, but only has 50 MB of
> data in it (I know, this is an extreme example!). With the tar method, you'll
> end up creating a file that actually consumes 2 GB of space; ufsdump will just
> either, but I could be wrong.
>
symbolic links.
I use cpio myself, but that's because I like to do perverted things
like reorder the files.
--
Howard Christeller Irvine, CA hchris...@home.com
Casper H.S. Dik - Network Security Engineer
Heiko Klein <REMOVEHeik...@ikp.uni-koeln.de> writes:
>I had problems with symlinks (owner change to root, though I used pP
>option).
>And tar doesn't handle ACL's.
It does as long as you specify the "p" option when extracting *and*
creating tar files.
D Becker
example# ufsdump 0f - /dev/rdsk/c0t0d0s7| (cd /home ; ufsrestore xf -)
In your case:
# newfs /dev/rdsk/c0t1d0s2
# mount /dev/dsk/c0t1d0s2 /mnt
# ufsdump 0f - /dev/rdsk/c0t0d0s2 | (cd /mnt ; ufsrestore xf -)
No expert here but above should work - I have something similar in the
past. No idea on which is fastest however.
In article <8k116m$k59$1...@slb7.atl.mindspring.net>, "Noone"
<no...@no.com> wrote:
>dd takes too long as it copies all the blocks regardless of if anything is
>written on them or not.
>
>I use the following that works great for me:
>
>1. Format drive to create partitions that are similar size (don't have to
>exact blocks)
>2. newfs each slice
>3. cd fromdir; tar xf - . | (cd todir; tar xfBpv -) (look at the man page
>on
>tar. This is directly from there. I may have missed an option). Do this
>for
>each slice.
>
>This works faster than dd or ufsdump. I have only tried ufsdump to a tape
>and then restore.
>
>
>"Kit-pui Wong" <86040175@$MAILHOST> wrote in message
>news:8jpl6r$8...@news.cityu.edu.hk...
>> dd let me "mirror" a disk to another perfectly
>> but ufsdump failed to do.
>>
>> Here're the command that I used. It finished successfully
>> and the new disk is bootable !
>>
>> # dd if=/dev/rdsk/c0t0d0s2 of=/dev/rdsk/c0t1d0s2 bs=1024k
>> # installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk
>/dev/rdsk/c0t1d0s0
>> # fsck -o p /dev/dsk/c0t1d0s0
>>
>>
>> I did simialarly with ufsdump but it failed. The file system
>> (if any) on the new disk couldn't even be mounted !
>>
>> # ufsdump 0uDf /dev/rdsk/c0t1d0s2 /dev/rdsk/c0t0d0s2
>> # installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk
>/dev/rdsk/c0t1d0s0
>> # fsck -o p /dev/dsk/c0t1d0s0
>>
>> I therefore "feel" that ufsdump is less capable than dd
>> to mirror a disk. What's your opinion ?
>>
>> cheers,
>> KiT
>>
no one
<8jpl6r$8...@news.cityu.edu.hk>:
>dd let me "mirror" a disk to another perfectly
>but ufsdump failed to do.
>
>Here're the command that I used. It finished successfully
>and the new disk is bootable !
>
># dd if=/dev/rdsk/c0t0d0s2 of=/dev/rdsk/c0t1d0s2 bs=1024k
># installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk
>/dev/rdsk/c0t1d0s0 # fsck -o p /dev/dsk/c0t1d0s0
>
>
>I did simialarly with ufsdump but it failed. The file system
>(if any) on the new disk couldn't even be mounted !
>
># ufsdump 0uDf /dev/rdsk/c0t1d0s2 /dev/rdsk/c0t0d0s2
># installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk
>/dev/rdsk/c0t1d0s0 # fsck -o p /dev/dsk/c0t1d0s0
>
>I therefore "feel" that ufsdump is less capable than dd
>to mirror a disk. What's your opinion ?
>
>cheers,
>KiT
>
When you play with the devil you will get burned. Trust me on this one.
dd is a great program if you know exactly what you're doing, but there are
bunches of caveats: the two big ones are that the disks must have identical
geometries (like another poster said), and you must be 100% sure that the
source disk is totally idle when you do the dd copy of its raw device.
I got burned working on an NCR teradata plex because the blasted
installation guys told management that they could clone an online system by
dd-ing the drives and management wouldn't listen to us low-life leased
worker SAs. They spent months redoing the new system because they didn't
do it right in the first place and ran a corrupt system for weeks before
the corruption showed up. I quit right in the middle of this puck-up
because I wouldn't clean up their messes after telling them this would
happen in the first place.
Don't use dd for copying disks except in very rare situations where there
is no alternative, but then there are always alternatives.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
no one
<8jpl6r$8...@news.cityu.edu.hk>:
>dd let me "mirror" a disk to another perfectly
>but ufsdump failed to do.
>
>Here're the command that I used. It finished successfully
>and the new disk is bootable !
>
># dd if=/dev/rdsk/c0t0d0s2 of=/dev/rdsk/c0t1d0s2 bs=1024k
># installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk
>/dev/rdsk/c0t1d0s0 # fsck -o p /dev/dsk/c0t1d0s0
>
>
>I did simialarly with ufsdump but it failed. The file system
>(if any) on the new disk couldn't even be mounted !
>
># ufsdump 0uDf /dev/rdsk/c0t1d0s2 /dev/rdsk/c0t0d0s2
># installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk
>/dev/rdsk/c0t1d0s0 # fsck -o p /dev/dsk/c0t1d0s0
>
>I therefore "feel" that ufsdump is less capable than dd
>to mirror a disk. What's your opinion ?
>
>cheers,
>KiT
>
I see another problem. Unless s2 is a single partition, you cannot use
ufsdump in the manner you describe. It works only on single partitions.
Also, you're using the rdsk devices. I don't think that you can do this.
And, I see another problem. ufsdump stores its data in a special format.
You use ufsrestore to restore the data. If I read your command line
correctly, then you just copied s2 from one disk to s2 on the other disk,
but in ufsdump format, not its native disk format.
ko...@my-deja.com
In article <8jpl6r$8...@news.cityu.edu.hk>,
> I therefore "feel" that ufsdump is less capable than dd
> to mirror a disk. What's your opinion ?
You might have done something wrong, because i copy my
harddisks with dump/restore all the time.
First of all, it is not a good idea to "dd" the first
cylinder of a harddisk to another one, even if they are
of the same type. So "dd"-ing the first partition or the
whole disk (via c-partition) is a no-no.
Second, if the filesystem isn't full, it might be faster
to use dump/restore. If i use "fastfs" to switch off
synchroneous writes of directories and inodes, dump/restore
is faster even if the filesystem is about 50% full.
But copying a 90% full /usr partition is a good idea.
Tschuess
Peter