1. 08 Nov, 2017 1 commit
  2. 11 Jan, 2017 1 commit
  3. 31 Oct, 2016 1 commit
    • Mike Hibler's avatar
      Deal with a nasty circular dependency when destroying a blockstore. · f0f635c7
      Mike Hibler authored
      If we destroy the Blockstore DB state first and then the server-side object
      destruction fails, we leave behind a dangling object and potentially Lease DB
      state. But if we destroy the object first and the DB state removal fails,
      we are left with a blockstore with no server-side object and thus we cannot
      look it up in the future to retry the destruction.
      
      We choose to go with the latter and just create a tiny server-side stub
      object if the DB state removal fails.
      f0f635c7
  4. 03 Oct, 2016 1 commit
  5. 28 Jan, 2015 1 commit
    • Mike Hibler's avatar
      Implement "plan 1" for dataset sharing: "ephemeral RO snapshots". · 7aefdaa1
      Mike Hibler authored
      You can now simultaneously RW and RO map a dataset because all the RO
      mappings use copies (clones) of a snapshot. Only a single RW mapping
      of course.
      
      When the RW mapping swaps out it automatically creates a new snapshot.
      So there is currently no user control over when a version of the dataset
      is "published", it just happens everytime you swapout an experiment with
      a RW mapping.
      
      A new RW mapping does not affect current RO mappings of course as they
      continue to use whatever snapshot they were created with. New RO mappings
      with get the most recent snapshot, which we currently track in the DB via
      the per-lease attribute "last_snapshot".
      
      You can also now declare a lease to be "exclusive use" by setting the
      "exclusive_use" lease attribute (via modlease). This means that it follows
      the old semantics of only one mapping at a time, whether it be RO or RW.
      This is an alternative to the "simultaneous_ro_datasets" sitevar which
      enforces the old behavior globally. Primarily, I put this attribute in to
      prevent an unexpected failure in the snapshot/clone path from wreaking
      havoc over time. I don't know if there is any value in exposing this to
      the user.
      7aefdaa1
  6. 29 Jan, 2014 1 commit
  7. 03 Jan, 2014 1 commit
  8. 11 Dec, 2013 5 commits