SUMMARY: Another quick dd question

Question:
=========
Is there any way to stop copying the VTOC from the source to the destination
disk with "dd"?  i.e.  can you only copy a single slice, instead of using s2
for
the entire disk?  Thanks so much.

I have tried:

dd if=/dev/rdsk/c0t0d0s0 of=/dev/rdsk/c0t1d0s0 bs=4096k

but it still wants to copy the VTOC - or am I just blind?

Solution:
=========
If you copy the entire slice 0, or 2, you will get the VTOC as well.  The way
to avoid this is
to use the command:

dd if=/dev/rdsk/c0t0d0s0 of=/dev/rdsk/c0t1d0s0 bs=512 skip=1

This is very slow, but does the job in the end.

Received Answers:
=================
Russ Poffenberger <poffen@san-jose.tt.slb.com>

Slice 0 probably starts at the beginning of the disk, right? That is where
the
VTOC is. The block mode driver knows how to step around the VTOC, but anytime
you use the raw device, it will include the VTOC if the slice uses cylinder
0.
If you use a slice that does not include the VTOC, then it will not be
copied.
-----------------------------------------------------------------------------
-------------------
Fabrice Guerini <fabrice@bluemartini.com>

Of course. Just make sure that your receiving slice is as large, or larger,
than the origin.
-----------------------------------------------------------------------------
-------------------
Homan, Charles (NE) <Charles.Homan@GDC4S.Com>

dd if=/dev/rdsk/c0t0d0s0 of=/dev/rdsk/c0t1d0s0 bs=512 skip=1

Sadly, because the VTOC is 512 bytes you have to use that as your block size
to skip the VTOC.  The good news is that slices other than s0 don't have
this issue, since the VTOC is only at the start of the disk.
-----------------------------------------------------------------------------
-------------------
Darren Dunham <ddunham@taos.com>

The VTOC is in the first block of the disk.  If your slice 0 uses
cylinder 0, then it will cover the first block of the disk.

If you have a UFS filesystem on it, you can skip the first 16 blocks.
They're not used in case you put it on cylinder 0, where it would
overwrite the VTOC and any boot blocks.

Or just skip the first block to avoid copying the VTOC.

The only time skipping would be a problem is if you're copying a slice
with raw data in it that is written in the first block.
-----------------------------------------------------------------------------
-------------------
Matthew Stier <Matthew.Stier@fnc.fujitsu.com>

Blind.

Unfortunately, slice 0 does contain the VTOC in the first blocks.  You can
use
'iseek' and 'oseek' to skip over the vtoc.  Of course I don't have the values
for
bs, iseek, and oseek available.
-----------------------------------------------------------------------------
-------------------
Manesh, Nasser (CAP, PTL) <nasser.manesh@penske.com>

Slice 0 happens to have the VTOC because VTOC is stored in
the first block of the disk.  If you do it with other slices
you will not see VTOC copied.  There are workarounds if you
definitely need to do it on slice 0 without copying VTOC but
they could be dangerous and you have to be careful.  One is
supplying offset when you dd.  The other is to make a backup
of the first block of the target disk using a separate dd
command, do your dd, and then restore it with a third dd
command.  Since my memory does not help me as to if VTOC is
in sector 0 or 1, I cannot give you exact commands, but that
is easy to find with a search.
-----------------------------------------------------------------------------
-------------------
Darren Dunham <ddunham@taos.com>

Well, I probably wouldn't be 'dd'ing if this were a concern.  :-)

You could use a small block size and just skip the first one..

# 1 block blocks (very slow), skips the VTOC
dd if=/dev/rdsk/c0t0d0s0 of=/dev/rdsk/c0t1d0s0 bs=1b skip=1

# 8k blocks (slightly faster), skips the VTOC and any boot blocks
# Should still copy any UFS filesystem.
dd if=/dev/rdsk/c0t0d0s0 of=/dev/rdsk/c0t1d0s0 bs=8k

If that's just too slow, then you'd have to do 2 copies.  One to do most
of the disk, and the other to get any blocks it doesn't..

# Copy blocks 1-8192 and then all blocks from 8192 onward...
dd if=/dev/rdsk/c0t0d0s0 of=/dev/rdsk/c0t1d0s0 bs=1b skip=1 count=8192
dd if=/dev/rdsk/c0t0d0s0 of=/dev/rdsk/c0t1d0s0 bs=4096k skip=1

At that point, I'd probably have given up on 'dd' and done something
else (like ufsdump | ufsrestore).
-----------------------------------------------------------------------------
-------------------
Michael Maciolek <mikem@noop.org>

You _can_ copy individual partitions, not just slice 2.  Make
absolutely certain that the destination slice is big enough to
hold the source slice.

Keep in mind that 'dd' knows nothing of disk layouts or VTOCs.
It's a simple-minded tool that reads and writes blocks in a
variety of ways; it doesn't know or care about the device on
which those block reside.
-----------------------------------------------------------------------------
-------------------
Brett Lymn <blymn@baesystems.com.au>

That is because the VTOC is part of s0, it is right at the front of
the disk.
-----------------------------------------------------------------------------
-------------------
Sergio Luiz Novaes <algol@lcc.ufmg.br>

I think you already has  an answer, but if not, s0 has the first disk
sector (is start on cilinder 0) and in this sector you have the VTOC. So if
you copy the raw device using s0 it will copy the VTOC also. So skip the
first sector (I don't know how, sorry) and every thing you work fine.
-----------------------------------------------------------------------------
-------------------
Riddoch, John E SITI-ITDSEP3 <John.E.Riddoch@is.shell.com>

Use fmthard/prtvtoc instead; it's more reliable and works.
-----------------------------------------------------------------------------
-------------------
Vahid Moghaddasi <sunman@ureach.com>

dd works on slice as well, but they have to be exactly identical.
-----------------------------------------------------------------------------
-------------------
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers