[OpenAFS] Re: 1.6.1a migration from 1.4: corrupted and offline volumes

Derrick Brashear shadow@gmail.com
Wed, 19 Sep 2012 11:48:11 -0400

Ah. Yup. Something like this:

     UserId author;             /* Userid of the last user storing the file */
     UserId owner;              /* Userid of the user who created the file */
     VnodeId parent;            /* Parent directory vnode */
-    bit32 vnodeMagic;          /* Magic number--mainly for file server
+    bit16 vnodeMagic;          /* Magic number--mainly for file server
                                 * paranoia checks */
-#   define       SMALLVNODEMAGIC       0xda8c041F
+#   define       SMALLVNODEMAGIC       0xda8c
 #   define       LARGEVNODEMAGIC       0xad8765fe
     /* Vnode magic can be removed, someday, if we run need the room.  Simply
      * have to be sure that the thing we replace can be VNODEMAGIC, rather
      * than 0 (in an old file system).  Or go through and zero the fields,
      * when we notice a version change (the index version number) */
+       unsigned int    isMigrated:1;
+       unsigned int    rsvd7:1;
+       unsigned int    serverUseDay:14;
     ViceLock lock;             /* Advisory lock */
     Date serverModifyTime;     /* Used only by the server; for incremental
                                 * backup purposes */

So what's required is either to patch your 1.6 to be special, or
migrate the volumes using vos move instead
of relying on the data format on disk being the same (which it isn't)

On Wed, Sep 19, 2012 at 11:16 AM, Andrew Deason <adeason@sinenomine.net> wrote:
> On Wed, 19 Sep 2012 15:37:39 +0200
> Jakub Moscicki <jakub.moscicki@cern.ch> wrote:
>> I just tried to deploy 1.6.1a on linux, migrating from 1.4 server. I
>> compiled from tar.gz sources and copied executables to /usr/afs/bin
>> This operation has put all my volumes offline with the following
>> FileLog entries:
>> Wed Sep 19 13:54:48 2012 GetBitmap: addled vnode index in volume
>> q.afs.st.afs211.fb.1; volume needs salvage
> Doesn't CERN use some modified backend code that changes the vnode magic
> for files? I thought I heard this was done for rxosd (or it's
> predecessor) or something. A modified on-disk format is not going to
> work with vanilla OpenAFS, and as far as I know that's exactly the error
> you would get doing it.
> If I'm way off, then nevermind, but... that's not a "normal" error to
> get. Unfortunately we don't print out what the 'bad' magic was, but if
> you copy the files in one of the 'special' directories in /vicepfb (just
> find one of the directories named 'special') and make them available,
> one of us could see what it is.
> --
> Andrew Deason
> adeason@sinenomine.net
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info