Hello,
OK, thanks, indeed it looks like a problem of a particular cell only...
sorry for the confusion.
Derrick: looking at a larger picture, is there a plan to integrate (some
of) these patches into the main repo in the future?
Many thanks,
kuba
Best regards,
Jakub Moscicki
On 09/19/2012 08:31 PM, Derrick Brashear wrote:
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 <[email protected]> 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 <[email protected]> wrote:
On Wed, 19 Sep 2012 15:37:39 +0200
Jakub Moscicki <[email protected]> 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
[email protected]
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
--
Derrick
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
