Xref: utzoo comp.sys.mips:1735 comp.unix.wizards:25993
Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!sobeco!sdesmara
From: sdesmara@sobeco.com (s.desmarais)
Newsgroups: comp.sys.mips,comp.unix.wizards
Subject: Re: dvhtool and prtvtoc weirdness
Message-ID: <1991Jun17.165241.26644@sobeco.com>
Date: 17 Jun 91 16:52:41 GMT
References: <34144@shamash.cdc.com>
Organization: Groupe Sobeco, Montreal, Canada
Lines: 54

In <34144@shamash.cdc.com> jeff@u02.svl.cdc.com (Jeff Needham) writes:

>Mips 6280/VME/Interphase controllers/Wren VI half-heights

>Small incongruity:  I use dvhtool to read in the volume header,
>repartition the thang and rewrite the whole mess back onto the
>disk.  It told me it wrote the header onto 15 tracks.

>When I read it back it looks like what I wrote.  prtvtoc on the
>other hand reads a partition table that looks like what was there
>before, even with -l.  Since -l asks the driver, it would appear
>that I need to re-acquaint the driver with the drive.  

First, be sure to use the character device (/dev/rdsk/...) and not the
block device (/dev/dsk/...).  Second, at least on our 6280 with 4.51,
one time out of 2 dvhtool complains about not being able to read the
volume header:
	 /etc/dvhtool

	Command? (read, vd, pt, dp, write, bootfile, or quit): read
	Volume? /dev/rdsk/ipc0d0vh
	Invalid volume header checksum.

	Command? (read, vd, pt, dp, write, bootfile, or quit): read
	Volume? /dev/rdsk/ipc0d0vh

	Command? (read, vd, pt, dp, write, bootfile, or quit):

As you see, just try more than one time, and it will work.

If you don't use the raw device, it seems that modification are never
written to disk.  Even with a reboot.

Second, we've also noticed that prtvtoc doesn't seem to read from the
device, but from the OS cache.

>Is boot the only way?

We haven't find another way.  We dvhtool all the disks that we need,
and reboot. Sign.

By the way, I don't recall exactly, but I think that at one point we
tried to newfs.ffs one freshly repartitioned disk without reboot, and
it didn't like it.  Unfortunately, I don't have a spare disk rigth now
to retest that.  Feel free...

>jeff
>| Jeffrey Needham
>| Control Data - Santa Clara, CA - INTERNET jeff@hawk.svl.cdc.com
-- 
Stephane M. Desmarais               sdesmara@sobeco.com  ou  sdesmara@sobeco.ca
Division STS - Groupe Sobeco Inc.   {uunet | mcgill-vision}!sobeco.com!sdesmara
505 boul Rene-Levesque Ouest        bur: (514) 878-9090 poste 297
Montreal, Quebec CANADA H2Z 1Y7     fax: (514) 875-2673  dom: (514) 733-3245