Differences between revisions 28 and 29
Revision 28 as of 2008-09-10 14:53:11
Size: 7413
Editor: FelixFrank
Comment: server upgrade (rxosd + fs)
Revision 29 as of 2008-10-30 11:40:24
Size: 7413
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
[[TableOfContents]] <<TableOfContents>>

SVN test repository

(!) Original openafs-1.4.7 sources were checked into revision 2.

The URL is file://localhost/afs/ifh.de/user/f/ffrank/osd_svn. ACLs currently allow user ffrank only.

Creating the patch

{{{ cd trunk/openafs-1.4.7 svn diff -r 2:HEAD -x -b >| ../full-patch }}} The -x -b option causes svn to ignore whitespace near eol (like diff -w).

iokaste crash recovery 2008-04-17

  • syslog unconclusive
  • AFS logs held no hints, either
    • update 2008-05-26: the problems with fs replaceosd were likely related to version mismatches between io and iokaste (fs != rxosd)

patch analysis

general problems and remarks

  • OSD awareness is not strictly protected by #ifdefs. VolSplit for example sports osd flags wether compiled in or not.

    • should/can the xg files respect definition of AFS_RXOSD_SUPPORT?
    • is it feasible to engross the declaration of, say, UV_CreateVolume2 in a way that uses OSD-specific parameter(s) only if enabled?

      • inserting alternative calls will be fairly easy on the other hand
        Answer
        This is basically reserving of spare fields, and extra info doesn't hurt seeing as its use is #ifdef-ed.
  • can fs fidvnode be done without OSD support enabled?

  • Answer
    Being implemented right now.
  • the fid* subcommands to fs sort of pollute its range of subcommands, fs help has gone quite long

    • could not a fid be specified in place of the file name in any case? or is ambiguity too great an issue?
      • in the latter case, ambiguity could be caught and reported as an error, forcing the user to specify a parameter to choose
        Answer

        We don't really want that, as fids are generally valid file names as well. Enlonging fs help output is tragic but to be solved in another way, if at all.

  • AFSFetchStatus.SyncCount is still used in WINNT/afsd/cm_[sd]cache.c

    • however, these are only initializations, the values are apparently never used, so it should be OK to erase/replace the initializations?
      Status
      fixed in the branch already, will be backported to trunk after build test

unidentified snippets

  • {o} src/viced/afsfileprocs.c:2472

    • Hartmut inserted an #ifdef AFS_NT40_ENV protecting two functions and some definitions. Probably a fix.

      Answer
      As the calls to the functions were thus #ifdef-ed already, so are their definitions now.
  • {o} src/viced/afsfileprocs.c:229

    • this function is declared here in Hartmuts code. not yet sure why. probably because of the use introduced into common_StoreData64. not yet sure what kind of fixes are hidden here and to what extent they're required. Watch patches for calls to common_StoreData64!

      Answer

      There have been changes to their structure and some unification. It has to do with the different prefixes SAFS_ and SRXAFS_.

  • {o} src/viced/afsfileprocs.c:3715

    • as mentioned above, the function common_StoreData64 was patched quite a bit. might have to ask Hartmut.

  • {o} src/viced/afsfileprocs.c:4858

    • looks like a bug fix
      Answer
      The concept of file quota is new and interesting for MR/wipeable volumes.
  • {o} src/viced/afsfileprocs.c:5283

    • this line moved inside the following if block. bug fix?
      Answer
      Yes.
  • /!\ src/viced/afsfileprocs.c:7379

    • this appears to be lacking the matching setActive()
    • (!) probably matched to the ones in GiveUpCallBacks() and GiveUpAllCallbacks(), but cannot be sure yet.

      Answer
      It's about right.
  • afsfileprocs.c:
    • {o} static char *locktype[4]

      • what's this about?
    • {o} SRXAFS_SetVolumeStatus

      • something was stripped from here?
  • {o} fs.c

    • Hartmut seems to pass NULL instead of 0 to cmd_CreateSyntax conventionally. Where the hell is the declaration for this? Looks like a style fix/correction.

      Answer
      Yes. It had been done in 1.4.7 in some places, anyway, and it's correct.
  • {o} vol/vnode.c

    • This new log message is more compelling. I'd have included this in the fs_listvnode patch but it looks like a general fix and should go into a general patch as that.
  • {o} fsint/afsint.xg:136

    • Looks like a common sense fix to exclude negative values here.
      Answer
      Pretty much. Allows for larger numbers, too.
  • {o} general question: why does fs vnode not work without OSD support in code.

    • have i missed something?
    • are vnodes fundamentally different with Hartmut's code? this couldn't be - it's interoperable w/ vanilla openafs when not build with --object-storage
      Answer
      There are still bugs.
  • {o} volser/vsutils.c:469

    • this also has a fix-ish look to it
      Answer
      Allows for a read to terminate after the VolID (i.e. at the first '.')
  • {o} venus/kdump.c

    • not understood yet what this does at all
      Answer
      This is a debug utility that's supposed to allow the user to peek inside the kernel. According to Hartmut, there's trouble with 64-bit.
  • {o} vol/fssync.c

    • exactly what is that "good idea" and what do the other changes do?
      Answer
      GOOD_IDEA is just a random define to make new code visible better.
  • {o} venus/fs.c:155

    • why is InitializeCBService() protected by #ifdef AFS_RXOSD_SUPPORT?

    • ListOffline() depends on it, but the command definition is not protected. Which one's the error here?

      Answer
      Most subcommand probably don't really need it. Its required when inquiring about files that are in object storage.
  • {*} venus/fs.c:3306

    • this looks like a fix but i can't quite figure it out
      Answer
      Actually that was an addition to the funcionality (changing work station cell on the fly).
  • {o} Makefile.in

    • target vol is now dependency of both viced and afsd. how come?

    • from a certain rm -rf statement, Hartmut deleted the ${SYS_NAME} argument. why?

  • vol/vol-salvage.c
    • {o} 2939: why introduce the length variable here?

isolating vos splitvol

  • sought through the patch, identifying places where
    • the client command was changed
    • the server was given the extra RPC
  • used vimdiff to introduce changes into

    • rxgen file
    • vos implementation
    • volser implementation

    and added the new vol_split.c code file, therefore

    • also updating volser's Makefile.in

  • Conclusion

    It turns out that the volsplit functionality depends on the reverse lookup functionality, also new with the full patch. Thus isolating volsplit failed at this stage and must be postponed until reverse lookups have been isolated.

    Addendum

    Apparently, InverseLookup is only used by vos splitvol, so both possibly belong in the same sub patch. For better

Making the Rxosd server a fileserver+Rxosd server

  1. osd setosd 12 -wrprior 0 
    where 12 is the ID of the OSD we want cleared.
  2. for fid in `vos listobjects 12 iokaste` ; do fs fidreplaceosd $fid 12 ; done 

    vos listo 12 iokaste returns the object ids of all objects stored on OSD 12 and metadata in volumes on iokaste.

  3. osd deleteosd 12 
  4. bos restart io rxosd 
  5. unmount /vicepe and create new filesystem (data is still being kept otherwise, salvager tries and creates non-attachable volumes from what's left on the disk)

  6. mount /vicepe

  7. touch file OnlyRxosd on vice partitions a-d

  8. create the fs instance on io

AfsOsd/Logs (last edited 2009-02-16 11:05:51 by FelixFrank)