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

[Troy Benjegerdes]

Is that in the main openafs git tree RxOSD branch, or some other patch?

On Wed, Sep 19, 2012 at 11:48:11AM -0400, Derrick Brashear wrote:
> 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
> >
> 
> 
> 
> -- 
> Derrick
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info