[OpenAFS-devel] -server argumant in vos listvldb ignored.

Wed, 11 Feb 2004 08:41:52 -0500

--0__=08BBE4A4DFDA60498f9e8a93df938690918c08BBE4A4DFDA6049
Content-type: multipart/alternative; 
	Boundary="1__=08BBE4A4DFDA60498f9e8a93df938690918c08BBE4A4DFDA6049"

--1__=08BBE4A4DFDA60498f9e8a93df938690918c08BBE4A4DFDA6049
Content-type: text/plain; charset=US-ASCII

Hi -

It almost sounds like you are worried that your VLDBs are
out of sync, that you suspect that one of your databases
contains incorrect location information.

You can use the "udebug -long" command and run it against
your sync site and then look at the the database versions
that are reported and determine if they are in sync or not

You would be looking for lines in the output like

Sync site's db version is 1076231019.3537
Server( 1.2.3.4 ): (db 1076231019.3537)
Server( 1.2.3.5 ): (db 1076231019.3537)

If all database versions are the same, then they should have the
same information in them.  If the DB versions are different,
then a transaction may be running the update on one of them or
there really might be a sync problem.

At that point, you can look at the log files on the DB server
machines to see if they are having problems syncing things
up.

======
======

If you really want to use the "vos command" to do your checking, you
can always do the following ::

 - create special versions of the /usr/vice/etc/CellServDB file that
   only contain ONE of your database servers for your cell.  So if
   you had 3 database server machines, you would have 4 versions of
   the CellServDB file
      1 with ALL db servers
      1 with only server 1
      1 with only server 2
      1 with only server 3

 - since commands like vos, pts, kas, klog, backup determine which
   database server to go to by reading the /usr/vice/etc/CellServDB
   file, you can then create a script which updates this file before
   issuing your special vos commands

      cp /usr/vice/etc/CellServDB.server1 /usr/vice/etc/CellServDB
      vos listvldb .........

            the above command will just go to the only DB-Server
            listed in the CellServDB file (server1)

      cp /usr/vice/etc/CellServDB.server2 /usr/vice/etc/CellServDB
      vos listvldb ....

            the above will query server2's VLDB

      cp /usr/vice/etc/CellServDB.server3 /usr/vice/etc/CellServDB
      vos listvldb ...

            the above will only query server3's VLDB

      cp /usr/vice/etc/CellSerdb.all /usr/vice/etc/CellServDB

            the above restores all 3 servers into your CellServDB file

That is one way to force a vos command to only go to a certain VLDB.

Thanks

Todd

                      Jimmy Engelbrecht                                                                                              
                      <jimmy@e.kth.se>            To:       Hartmut Reuter <reuter@rzg.mpg.de>                                       
                      Sent by:                    cc:       openafs-devel@openafs.org                                                
                      openafs-devel-admin@        Subject:  Re: [OpenAFS-devel] -server argumant in vos listvldb ignored.            
                      openafs.org                                                                                                    

                      02/11/2004 06:30 AM                                                                                            

Hartmut Reuter <reuter@rzg.mpg.de> writes:

> The server argument for vos listvldb is used to restrict the databse
search
> to volumes with instances on a certain fileserver.

Hmm i understand, but in the case "-name" is given it seems to do nothing,
right ?

$ /usr/afsws/sbin/vos listvldb -server cool-fileserver.reuter.de -name
mpkg.i386_rh72 -noauth

mpkg.i386_rh72
    RWrite: 536959307     ROnly: 536959308     Backup: 536959309
    number of sites -> 5
       server vivo.e.kth.se partition /vicepa RW Site
       server vivo.e.kth.se partition /vicepa RO Site
       server rimi.e.kth.se partition /vicepa RO Site
       server konsum.e.kth.se partition /vicepa RO Site
       server prisextra.e.kth.se partition /vicepa RO Site

> It doesn't allow to specify the address of the database server to be
> contacted.

Hmmm, so what i want to do is not possible with openafs ?

/Jimmy
_______________________________________________
OpenAFS-devel mailing list
OpenAFS-devel@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-devel

--1__=08BBE4A4DFDA60498f9e8a93df938690918c08BBE4A4DFDA6049
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline

<html><body>
Hi - 
 
It almost sounds like you are worried that your VLDBs are 
out of sync, that you suspect that one of your databases 
contains incorrect location information. 
 
You can use the &quot;udebug -long&quot; command and run it against 
your sync site and then look at the the database versions 
that are reported and determine if they are in sync or not 
 
You would be looking for lines in the output like 
 
Sync site's db version is 1076231019.3537 
Server( 1.2.3.4 ): (db 1076231019.3537) 
Server( 1.2.3.5 ): (db 1076231019.3537) 
 
If all database versions are the same, then they should have the 
same information in them. If the DB versions are different, 
then a transaction may be running the update on one of them or 
there really might be a sync problem. 
 
At that point, you can look at the log files on the DB server 
machines to see if they are having problems syncing things 
up. 
 
====== 
====== 
 
If you really want to use the &quot;vos command&quot; to do your checking, you 
can always do the following :: 
 
 - create special versions of the /usr/vice/etc/CellServDB file that 
 only contain ONE of your database servers for your cell. So if 
 you had 3 database server machines, you would have 4 versions of 
 the CellServDB file 
	1 with ALL db servers 
	1 with only server 1 
	1 with only server 2 
	1 with only server 3 
 
 - since commands like vos, pts, kas, klog, backup determine which 
 database server to go to by reading the /usr/vice/etc/CellServDB 
 file, you can then create a script which updates this file before 
 issuing your special vos commands 
 
	cp /usr/vice/etc/CellServDB.server1 /usr/vice/etc/CellServDB 
	vos listvldb ......... 
 
		the above command will just go to the only DB-Server 
		listed in the CellServDB file (server1) 
 
	cp /usr/vice/etc/CellServDB.server2 /usr/vice/etc/CellServDB 
	vos listvldb .... 
 
		the above will query server2's VLDB 
 
	cp /usr/vice/etc/CellServDB.server3 /usr/vice/etc/CellServDB 
	vos listvldb ... 
 
		the above will only query server3's VLDB 
 
	cp /usr/vice/etc/CellSerdb.all /usr/vice/etc/CellServDB 
 
		the above restores all 3 servers into your CellServDB file 
 
That is one way to force a vos command to only go to a certain VLDB. 
 
Thanks 
 
Todd 
 
<img src="cid:10__=08BBE4A4DFDA60498f9e8a93df938@us.ibm.com" width="16" height="16" alt="Inactive hide details for Jimmy Engelbrecht &lt;jimmy@e.kth.se&gt;">Jimmy Engelbrecht &lt;jimmy@e.kth.se&gt;

<table V5DOTBL=true width="100%" border="0" cellspacing="0" cellpadding="0">
<tr valign="top"><td width="1%"><img src="cid:20__=08BBE4A4DFDA60498f9e8a93df938@us.ibm.com" border="0" height="1" width="72" alt=""><br>
</td><td style="background-image:url(cid:30__=08BBE4A4DFDA60498f9e8a93df938@us.ibm.com); background-repeat: no-repeat; " width="1%"><img src="cid:20__=08BBE4A4DFDA60498f9e8a93df938@us.ibm.com" border="0" height="1" width="225" alt=""><br>

<ul>
<ul>
<ul>
<ul><b><font size="2">Jimmy Engelbrecht &lt;jimmy@e.kth.se&gt;</font></b><br>
<font size="2">Sent by: openafs-devel-admin@openafs.org</font>
<p><font size="2">02/11/2004 06:30 AM</font></ul>
</ul>
</ul>
</ul>
</td><td width="100%"><img src="cid:20__=08BBE4A4DFDA60498f9e8a93df938@us.ibm.com" border="0" height="1" width="1" alt=""><br>
<font size="1" face="Arial">	</font><br>
<font size="2">	To:	</font><font size="2">Hartmut Reuter &lt;reuter@rzg.mpg.de&gt;</font><br>
<font size="2">	cc:	</font><font size="2">openafs-devel@openafs.org</font><br>
<font size="2">	Subject:	</font><font size="2">Re: [OpenAFS-devel] -server argumant in vos listvldb ignored.</font></td></tr>
</table>
<br>
<br>
<tt>Hartmut Reuter &lt;reuter@rzg.mpg.de&gt; writes:<br>
<br>
&gt; The server argument for vos listvldb is used to restrict the databse search<br>
&gt; to volumes with instances on a certain fileserver.<br>
<br>
Hmm i understand, but in the case &quot;-name&quot; is given it seems to do nothing,<br>
right ?<br>
<br>
$ /usr/afsws/sbin/vos listvldb -server cool-fileserver.reuter.de -name mpkg.i386_rh72 -noauth<br>
<br>
mpkg.i386_rh72 <br>
 &nbsp; &nbsp;RWrite: 536959307 &nbsp; &nbsp; ROnly: 536959308 &nbsp; &nbsp; Backup: 536959309 <br>
 &nbsp; &nbsp;number of sites -&gt; 5<br>
 &nbsp; &nbsp; &nbsp; server vivo.e.kth.se partition /vicepa RW Site <br>
 &nbsp; &nbsp; &nbsp; server vivo.e.kth.se partition /vicepa RO Site <br>
 &nbsp; &nbsp; &nbsp; server rimi.e.kth.se partition /vicepa RO Site <br>
 &nbsp; &nbsp; &nbsp; server konsum.e.kth.se partition /vicepa RO Site <br>
 &nbsp; &nbsp; &nbsp; server prisextra.e.kth.se partition /vicepa RO Site <br>
<br>
&gt; It doesn't allow to specify the address of the database server to be<br>
&gt; contacted.<br>
<br>
Hmmm, so what i want to do is not possible with openafs ?<br>
<br>
/Jimmy<br>
_______________________________________________<br>
OpenAFS-devel mailing list<br>
OpenAFS-devel@openafs.org<br>
</tt><tt><a href="https://lists.openafs.org/mailman/listinfo/openafs-devel">https://lists.openafs.org/mailman/listinfo/openafs-devel</a></tt><tt><br>
</tt>

</body></html>

--1__=08BBE4A4DFDA60498f9e8a93df938690918c08BBE4A4DFDA6049--

--0__=08BBE4A4DFDA60498f9e8a93df938690918c08BBE4A4DFDA6049
Content-type: image/gif; 
	name="graycol.gif"
Content-Disposition: inline; filename="graycol.gif"
Content-ID: <10__=08BBE4A4DFDA60498f9e8a93df938@us.ibm.com>
Content-transfer-encoding: base64

R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu
ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7

--0__=08BBE4A4DFDA60498f9e8a93df938690918c08BBE4A4DFDA6049
Content-type: image/gif; 
	name="ecblank.gif"
Content-Disposition: inline; filename="ecblank.gif"
Content-ID: <20__=08BBE4A4DFDA60498f9e8a93df938@us.ibm.com>
Content-transfer-encoding: base64

R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7

--0__=08BBE4A4DFDA60498f9e8a93df938690918c08BBE4A4DFDA6049
Content-type: image/gif; 
	name="pic05928.gif"
Content-Disposition: inline; filename="pic05928.gif"
Content-ID: <30__=08BBE4A4DFDA60498f9e8a93df938@us.ibm.com>
Content-transfer-encoding: base64

R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA
AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh
EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR
RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH
LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK
BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI
TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR
M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG
uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg
zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb
qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33
YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw
NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0
2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco
CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w
2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE
V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH
ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT
mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw
9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb
jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl
fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA
Ow==

--0__=08BBE4A4DFDA60498f9e8a93df938690918c08BBE4A4DFDA6049--