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

Derrick Brashear shadow@gmail.com
Wed, 19 Sep 2012 14:31:10 -0400


it's some patch CERN applied to 1.4; I had email from long ago with it
and Andrew reminded me
that I'd seen it before, so I dug it out.

On Wed, Sep 19, 2012 at 2:29 PM, Troy Benjegerdes <hozer@hozed.org> wrote:
> 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



-- 
Derrick