1. 20 Jul, 2018 1 commit
  2. 05 Apr, 2018 1 commit
  3. 22 Mar, 2018 1 commit
    • Mike Hibler's avatar
      Bug fix: attempt to avoid hangs when creating blockstores on large SSDs. · a670b802
      Mike Hibler authored
      At least I think the problem is that we are doing inadvertent TRIM
      operations on large (480GB) SSDs. For one, when creating an ext4
      filesystem on such a blockstore, we specify "nodiscard". I toyed
      with the idea of turning off "issue_discards" for the lvremove
      operations when a blockstore is destroyed, but that led to old
      metadata being seen when the blockstore was re-created. That led
      to the last change, which was to force metadata zeroing when we
      do an lvcreate of a blockstore.
      a670b802
  4. 14 Nov, 2017 1 commit
  5. 29 Aug, 2017 1 commit
    • Mike Hibler's avatar
      Fix an ambiguous RE. · 9d887325
      Mike Hibler authored
      If one blockstore name was a subset of another (e.g., "foo" vs. "foo2")
      then the check code could get confused and not mount some iSCSI blockstores.
      9d887325
  6. 25 Mar, 2017 1 commit
  7. 24 Mar, 2017 1 commit
    • Mike Hibler's avatar
      Semi-hack to ensure that Wisconsin nodes don't include their SSDs · fbe5f38f
      Mike Hibler authored
      in blockstore-related VGs.
      
      Right now, you have to decide globally and in advance, what disk types
      are going to be included in blockstore pools. Then you set the sitevar
      accordingly and then set the DB sysvol/nonsysvol/any node_type_features
      to reflect the amount of storage available on just drives of that type.
      
      This value is passed to clients via the otherwise unused PROTO field
      of the blockstore line (when CMD=SLICE and CLASS=local), so this change
      is backward compatible (OS images with older client code will ignore it
      and just give you blockstores including all the devices).
      
      So at Wisconsin, I set storage/local/disktype to "HDD-only" and tweak
      the node_type_attributes '?+disk_any' and '?+disk_nonsysvol' to not
      include the space for the 1 or 2 SSD drives in each machine. tmcd passes
      the PROTO=HDD-only value and the client sees that and does not include
      any SSD devices among the eligible devices from which to create the VG.
      
      The hope is that ultimately, we could get rid of the sitevar and use the
      PROTO field to select, per-blockstore, its type (only HDD, only SSD).
      But that will require additional per node (type) assign features
      differentiating the amount of each type available.
      fbe5f38f
  8. 15 Mar, 2017 1 commit
  9. 15 Feb, 2017 1 commit
  10. 25 Jan, 2017 1 commit
  11. 19 Jan, 2017 1 commit
    • Mike Hibler's avatar
      Redo the frisbee heartbeat code again. · 5407463e
      Mike Hibler authored
      My "shortcut" to enable a heartbeat via a client-side command line
      proved to be untenable. There are just too many places where we fire
      off the client and getting the right heartbeat interval value to all
      those places would have been...challenging.
      
      So back to the original plan of having a server-side command line
      option and letting the server tell the client when/what to report.
      This limits the changes to just the frisbee master server, in particular
      I now just have to get the value to master server instances running
      on the subbosses (not done yet, just hardwiring a value for now).
      
      All this said, I still had to modify the various places we invoke
      the frisbee client to add an option to enable the heartbeat, but at
      least I didn't need to know a specific value.
      5407463e
  12. 09 Dec, 2016 1 commit
  13. 11 Nov, 2016 1 commit
    • Mike Hibler's avatar
      Fixes to LVM handling. · 85a42dd8
      Mike Hibler authored
      1. If the blockstore name has a '-' in it, the dm name will have '--'.
      2. The version of "lvs" in Ubuntu 16 has a new attribute in the output.
      85a42dd8
  14. 04 Oct, 2016 1 commit
  15. 13 Jul, 2016 2 commits
  16. 14 May, 2016 1 commit
  17. 07 Mar, 2016 1 commit
  18. 04 Mar, 2016 1 commit
  19. 05 Feb, 2016 1 commit
    • Mike Hibler's avatar
      Make "reset" operation work for blockstores. · 0b90ef4f
      Mike Hibler authored
      Reset on local/remote blockstores ensures that there is no blockstore related
      state left in the root filesystem (e.g., mounts in /etc/fstab, iSCSI config,
      LVM/ZFS state). It does this in such a way that upon reboot, all the necessary
      state is recreated.
      
      What this means is that you should now be able to take an image of a node
      that uses blockstores and have that image actually work on another node!
      Previously, there could/would be leftover blockstore turds that would make
      the new image fail to boot.
      
      Of course, this won't work until the standard images are remade and will
      then only work for those images or images derived from them.
      0b90ef4f
  20. 03 Feb, 2016 1 commit
  21. 26 May, 2015 1 commit
  22. 28 Apr, 2015 1 commit
  23. 30 Mar, 2015 1 commit
  24. 06 Mar, 2015 2 commits
  25. 05 Mar, 2015 1 commit
  26. 20 Feb, 2015 1 commit
    • Mike Hibler's avatar
      Support for GPT-based SYSVOL local blockstores. · d8b6eb6a
      Mike Hibler authored
      For the Moonshots. SYSVOL is the only one that matters right now since
      the Moonshots only have a single disk. But ANY and NONSYSVOL could be
      more difficult since you might have a mix of MBR and GPT disks. We'll
      get there when we get there.
      d8b6eb6a
  27. 10 Feb, 2015 1 commit
  28. 07 Nov, 2014 1 commit
  29. 09 Oct, 2014 1 commit
    • Mike Hibler's avatar
      Rework client-side storage scripts to semi-coexist with mkextrafs uses. · 9cf8f9c6
      Mike Hibler authored
      Broke rc.storage into two phases, local blockstores and remote blockstores.
      Setup of the former will also pick a best candidate for an old-school
      "extrafs" and put the info in /var/emulab/boot/extrafs. This will be a
      single line with one of DISK=foo, PART=foo, or FS=foo depending on whether
      it found an available full disk, disk partition, or mounted filesystem
      that we can use for mkextrafs (in the first two cases) or where we can
      mooch off of (the last). This is only used in os_mountextrafs() right now;
      i.e., I have NOT changed the mkextrafs script. So explicit invocations
      by the user could still screw things up.
      
      I have tested this with local blockstores and a non-nfs experiment
      on both Linux and FreeBSD to make sure the most common sharing of space
      works. I have not made any new images and I have not yet tested to make
      sure I did not break non-blockstore, non-nfs experiments (i.e., where
      we really should run mkextrafs).
      
      So maybe don't make any new images til I get back, or else be prepared
      to clean up after me.
      9cf8f9c6
  30. 22 Sep, 2014 1 commit
  31. 21 Feb, 2014 1 commit
  32. 10 Feb, 2014 1 commit
  33. 30 Jan, 2014 1 commit
  34. 23 Jan, 2014 1 commit
  35. 06 Dec, 2013 1 commit
  36. 04 Oct, 2013 1 commit
  37. 15 Aug, 2013 1 commit
    • Mike Hibler's avatar
      Change the semantics of "reset". · c30b122e
      Mike Hibler authored
      "reset" now just unmounts blockstores, it does not destroy them.
      Need this so that people can include a SYSVOL blockstore in a custom image
      (the only place where "reset" is used). Also, destroying blockstores would
      have come as an unpleasant surprise to anyone who created a custom image
      and then expected their data to still be around afterward!
      
      Also work around a bizzare bug in BSD sed that happens in the prepare script.
      That script does:
      
           sed -e '/# next line is swap device/,+1d' /etc/fstab
      
      which should remove the matched comment and the line after it (the swapdev
      entry). But if there are EXACTLY two additional lines after the matched line,
      it would remove both of them (effectively "+2")! So if there was a mount for
      a blockstore device after the swap device, prepare would remove that line too.
      
      So in the finest tradition of "if it hurts, don't do it", the blockstore code
      makes sure that it adds at least two additional lines.
      c30b122e
  38. 24 May, 2013 1 commit
    • Mike Hibler's avatar
      Whack! · 1fe8b203
      Mike Hibler authored
      Take care of an iSCSI race condition in Fedora15.
      1fe8b203