>Use 'vldbconvert -showversion' to CHECK THAT YOUR CURRENT DATABASE IS
>REALLY VERSION 3, not version 2. I had been running what I thought was
>AFS 3.3a for more than a year, but for whatever reason, the database
>format was still version 2. While it turned out later that 'vldbconvert
>-showversion' was able to report that fact, 'vldbconvert -from 3 -to 4'
>was not able to recognize its unability to convert the database.
>Instead, it produced a corrupted database without reporting any error.
>I have seen a lot of stupid programs, but this one probably qualifies
>as the most idiotic bug ever. As a result, the migration of my database
>servers appeared to have been done successfully. However, in the very
>second the first AFS 3.4 fileserver came up and registered itself with
>the VLDB server, the database server's attempt to convert the database
>ended up in a disaster. No volumes where accessible anymore, and 'vos
>listvldb' reported all volumes on a single server that didn't even
>exist at all (actually on the very first IP address that had been used
>for a fileserver during my cell's history).
Interesting. This sounds strangely familiar. Though in my case 'vos
listvldb' reported all volumes were housed on a Macintosh! Fortunately
when I called Transarc it turned out the fix was trivial: remove the
database and 'vos syncvldb <server>' once for each server. But they
never told me what the cause was. Now I guess the truth come out.
-Mitch
