1. 08 Jan, 2018 1 commit
    • David Johnson's avatar
      Add some debugging support to clientside TBScriptLock; use it in libvnode_xen. · 5d0ff72b
      David Johnson authored
      If the TBScriptLock caller provides a debug message, it will be stored
      in a file, and other blocked TBScriptLock callers will get (possibly
      slightly racy) info about who holds the lock.
      
      Then, use this in libvnode_xen to get some info about long calls to xl
      (create|halt|reboot|etc).
      
      Also enable lockdebug in libvnode_xen for now.
      5d0ff72b
  2. 22 Nov, 2017 1 commit
  3. 10 Nov, 2017 1 commit
  4. 09 Nov, 2017 1 commit
  5. 10 Oct, 2017 1 commit
  6. 03 Aug, 2017 1 commit
  7. 05 Jul, 2017 1 commit
    • Mike Hibler's avatar
      Force an fsck.ufs after localization of a FreeBSD filesystem. · 24787f2c
      Mike Hibler authored
      Apparently there are some issues with UFS2 support in Linux.
      Fsck mostly fixes incorrect block counts:
          INCORRECT BLOCK COUNT I=1043374 (0 should be 8)
      for inodes that get created by Linux (e.g., /etc/ssh host keys,
      /var/emulab/boot stuff). Everything seems to be fine after the fsck.
      
      Also: specify "-Zy" when creating LVMs so that old GPTs, superblocks, etc.
      don't leak through. LVM seems to be frightfully deterministic in its
      allocation strategies to the extent that virtual disks created in previous
      experiments have their metadata show up in newer experiment LVMs.
      All the things that are changed
      24787f2c
  8. 15 Jun, 2017 1 commit
  9. 02 Jun, 2017 1 commit
  10. 16 May, 2017 1 commit
  11. 11 Apr, 2017 1 commit
  12. 07 Apr, 2017 1 commit
  13. 30 Mar, 2017 1 commit
  14. 18 Mar, 2017 1 commit
  15. 10 Mar, 2017 1 commit
  16. 27 Feb, 2017 2 commits
  17. 16 Feb, 2017 1 commit
    • Mike Hibler's avatar
      More robustness improvements for FreeBSD vnodes. · aa9bc39b
      Mike Hibler authored
      Not sure how I got headed down this path, but here I am:
       * replace use of "ps" and "grep" with, wait for it..."pgrep"!
       * explicitly specify type=vif so we don't wind up with the extra,
         vifN.M-emu backend interface that gets left laying around,
       * add -F option to "xl shutdown" which is needed for HVMs else
         shutdown will fail and the domain won't go away (qemu left behind)
         and FBSD filesystem can be messed up,
       * Use "hd" instead of "sd" to avoid emulated SCSI driver which has
         caused me grief in the past (though it should never actually get
         used due to PVHVM config of kernel).
      aa9bc39b
  18. 15 Feb, 2017 1 commit
  19. 18 Nov, 2016 1 commit
  20. 24 Oct, 2016 1 commit
  21. 29 Sep, 2016 1 commit
    • Mike Hibler's avatar
      Performance improvements to the vnode startup path. · 87eed168
      Mike Hibler authored
      The bigest improvement happened on day one when I took out the 20 second sleep
      between vnode starts in bootvnodes. That appears to have been an artifact of
      an older time and an older Xen. Or, someone smarter than me saw the potential
      of getting bogged down for, oh say three weeks, trying to micro-optimize the
      process and instead just went for the conservative fix!
      
      Following day one, the ensuing couple of weeks was a long strange trip to
      find the maximum number of simultaneous vnode creations that could be done
      without failure. In that time I tried a lot of things, generated a lot of
      graphs, produced and tweaked a lot of new constants, and in the end, wound
      up with the same two magic numbers (3 and 5) that were in the original code!
      To distinguish myself, I added a third magic number (1, the loneliest of
      them all).
      
      All I can say is that now, the choice of 3 or 5 (or 1), is based on more
      solid evidence than before. Previously it was 5 if you had a thin-provisioning
      LVM, 3 otherwise. Now it is based more directly on host resources, as
      described in a long comment in the code, the important part of which is:
      
       #
       # if (dom0 physical RAM < 1GB) MAX = 1;
       # if (any swap activity) MAX = 1;
       #
       #    This captures pc3000s/other old machines and overloaded (RAM) machines.
       #
       # if (# physical CPUs <= 2) MAX = 3;
       # if (# physical spindles == 1) MAX = 3;
       # if (dom0 physical RAM <= 2GB) MAX = 3;
       #
       #    This captures d710s, Apt r320, and Cloudlab m510s. We may need to
       #    reconsider the latter since its single drive is an NVMe device.
       #    But first we have to get Xen working with them (UEFI issues)...
       #
       # else MAX = 5;
      
      In my defense, I did fix some bugs and stuff too (and did I mention
      the cool graphs?) See comments in the code and gitlab emulab/emulab-devel
      issue #148.
      87eed168
  22. 02 Sep, 2016 1 commit
  23. 31 Aug, 2016 1 commit
  24. 12 Aug, 2016 1 commit
  25. 28 Jul, 2016 1 commit
  26. 21 Jul, 2016 1 commit
  27. 07 Jun, 2016 1 commit
  28. 09 Feb, 2016 1 commit
  29. 04 Jan, 2016 1 commit
  30. 21 Dec, 2015 1 commit
  31. 01 Dec, 2015 1 commit
    • Leigh B Stoller's avatar
      Add an "interruptible" option to TBScriptLock(). When set, each time · 08ce72b6
      Leigh B Stoller authored
      through the loop we look to see if signals are pending, and if so we return
      early with an error. The caller (libvnode_xen) can use this to avoid really
      long waits, when the server has said to stop what its doing. For example, a
      vnode setup is waiting for an image lock, but the server comes along ands
      to stop setting up. Previously, we would wait for the lock, now we return
      early. This is to help with cancelation where it is nice if the server can
      stop a CreateSliver() in its tracks, when it is safe to do so.
      08ce72b6
  32. 24 Nov, 2015 2 commits
  33. 20 Nov, 2015 1 commit
  34. 27 Oct, 2015 3 commits
  35. 14 Oct, 2015 1 commit
  36. 26 Aug, 2015 1 commit