Conference turris::digital_unix

dd will work fine as long as the disk isn't mounted.

As for the bs= value, I think you can use up to 16M
for scsi devices (but it isn't going to go much faster
since you're spindle speed limited long before you get
to such a large blocksize).

I assume too since they didn't purchase S/W, that they
did atleast purchase a license, and that must still be
handled manually?

	Fred

	The last time I looked (around 1.3) a raw read that ended
	past the end of the device would fail, rather than return
	the amount of data left.  This means you'd miss some of the
	data at end of the device.  If this was changed, you're
	fine.  If not you need to use a block size that is a factor
	of the capacity.  Please note that the track size is often
	not a factor of the capacity.

	Since it had been slow long since I last looked, I decided
	to look again on a V4.0something system.  Short reads at
	end of devices now read what's left instead of failing.
	I vaguely recall a QAR I submitted on the inconsistency
	between devices and files...

Greetings!

  Watch the "bs=" setting for different disks, see note 7790.1 for details...


						Tony Swierkowski

	re: .3

	I tried my test program on V1.3 as well, and it works the
	better way there too.  Must have been ULTRIX.

Thank you for all replies. 

re: .1

They have purchased all the software and license but point is those are not 
"pre-installed."  We are OEM business so we sale parts.  Our OEM customer
sets up all the software hardware configuration and ship to the end user.
The end user will put license and reconfigure again (eg hostname, network 
configuration...).  So we don't give away anything. 

re: .4

I read 7790.1, but I don't seem to get the number right...  I have a rz28m
disk as follow (disklabel output below).  To get a block size, I calculate as.

	4,110,480 (sector/unit) x 512 (bytes/sector) = 2,104,565,760 bytes
	2,104,565,760 / 8192 (block) = 256,905 blocks.

So I get 256,905 blocks for this disk.  If 'bs' is 80b (40,960), this does
not divide correctly (256,905 / 40,960 = 6.272...).  So what am I missing ???

re: .5 

So what value of bs did you used in your test program ?  

After all, I don't lose the last block even the block size is not the
capacity of disk block.  So what should I use ???

Thanks,

K. Suruga


root@jaja# disklabel -r /dev/rrz0a
# /dev/rrz0a:
type: SCSI
disk: rz28m
label:
flags:
bytes/sector: 512
sectors/track: 99
tracks/cylinder: 16
sectors/cylinder: 1584
cylinders: 2595
sectors/unit: 4110480
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0           # milliseconds
track-to-track seek: 0  # milliseconds
drivedata: 0

8 partitions:
#        size   offset    fstype   [fsize bsize   cpg]
  a:   582144        0     AdvFS                        # (Cyl.    0 - 367*)
  b:   546980   582144      swap                        # (Cyl.  367*- 712*)
  c:  4110480        0    unused     1024  8192         # (Cyl.    0 - 2594)
  d:  1191936   532480    unused     1024  8192         # (Cyl.  336*- 1088*)
  e:  1191936  1724416    unused     1024  8192         # (Cyl. 1088*- 1841*)
  f:  1194128  2916352    unused     1024  8192         # (Cyl. 1841*- 2594)
  g:  2981356  1129124    4.2BSD     1024  8192    16   # (Cyl.  712*- 2594)
  h:  1790096  2320384    unused     1024  8192         # (Cyl. 1464*- 2594)
root@jaja#

	My test program got the size of a disk, did an lseek to a
	point two sectors back from the end, read 2 sectors, did
	the seek again and read 64 KB.  Neither failed and both
	read 1 KB.  Therefore, the SCSI driver behaves nicely (*).

	Without this constraint on the I/O size, you can use pretty
	much any I/O size you want.  A good size is a large one that
	is not so large that the buffer(s) needed for the I/O cause
	the system page.  64 KB is nearly always a safe size, but
	you can go larger.  Some devices may force the driver to
	limit the I/O size, but this is typically hidden by the
	driver.

    I think a dump | restore would be a better solution. It works, it
    copies all the files only and not the blank space, and may be better in
    the case of bad blocks on the disk devices- although that may be
    handled by the disk firmware itself.
    
    Either the dump or the restore (or vdump vrestore) man pages has the
    exact command line as an example.
    
    I have also done such a clone on systems with SWXCR controllers by
    making a mirror and just yanking one mirror out. Let teh hardware
    re-build another one for you.

Thank you for all the help.  After talking around, I found another way.
The btcreate/btrestore can backup entire disk and able to restore 
to equal or greater disk size.  I have tested in my workstation and worked
very nicely.  It requires Digital UNIX V4.0b.

I have to do more testing to determine recommendation to the customer. 

Thanks,

K. Suruga

    I use the AdvFS utilities vdump and vrestore.  YES, these utilities
    work with ufs.  YES these utilities actually work when you type in the
    example in the manpage for vrestore:
    
       # vdump -0f - /usr | vrestore -xf - -D /mnt
    
    Don't try dump - broke in Unix V4.0 and won't be fixed until Steel.  
    See QAR 47050.
    

    PS You'll need the following subsets when you install Unix:
    
    	Polyctr ADVfs kernel modules
    	Polyctr ADVfs
    

After some testing, I believe btcreate/btextract is the easiest way
to copy entire disk.  I can handle AdvFS as well.  The utility can restore
to different SCSI id disk by changing rc.config and fstab entries.

K. Suruga