[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