1. Jun 21, 2022
  2. Feb 22, 2022
  3. May 28, 2021
  4. Mar 30, 2021
  5. Feb 07, 2021
  6. Nov 25, 2020
  7. Jul 28, 2020
    • Marc Vef's avatar
      Refactoring daemon I/O logic and fixing truncate etc. · bcb30ac2
      Marc Vef authored and Alberto Miranda's avatar Alberto Miranda committed
      The `ChunkStorage` backend class on the daemon was throwing `system_errors` without being caught, crashing the server in the process. `ChunkStorage` now uses a designated error class for errors that might occur. In addition the dependency to Argobots was removed which was used to trigger `ABT_eventuals`, laying ground work for future non-Argobots IO implementations. Further, the whole class was refactored for consistency and failure resistance.
      
      A new class `ChunkOperation` is introduced which wraps Argobots' IO task operations which allows the removal of IO queue specific code within RPC handlers, i.e., read and write handlers. The idea is to separate eventuals, tasks and their arguments from handler logic into a designated class. Therefore, an object of an inherited class of `ChunkOperation` is instantiated within the handlers that drives all IO tasks. The corresponding code was added to the read and write RPC handlers. Note, `ChunkOperation` is not thread-safe and is supposed to be called by a single thread.
      
      In addition, truncate was reworked for error handling (it crashed the server on error) and that it uses the IO queue as well since truncate causes a write operation and should not overtake IO tasks in the queue.
      
      The chunk stat rpc handler was refactored for error handling and to use error codes as well. 
      
      Further minor changes:
      - dead chunk stat code has been removed
      - some namespaces were missing: `gkfs::rpc`
      - more flexible handler cleanup and response code
      - fixed a bug where the chunk dir wasn't removed when the metadata didn't exist on the same node
      bcb30ac2
  8. Feb 20, 2020
  9. Feb 10, 2020
  10. Feb 09, 2020
  11. Apr 24, 2019
  12. Apr 03, 2019
  13. Mar 05, 2019
  14. Oct 31, 2018
    • Tommaso Tocci's avatar
      use mercury automatic SM routing · c40be81b
      Tommaso Tocci authored
      Mercury now support shared memory autorouting.
      
      A single margo instance can be initialized and it will handle both
      shared memory communication and remote ones.
      
      If the endpoint of the RPC is local mercury will automatically use
      shared memory.
      
      Since there is only one margo instance all the duplicated code for
      rpc/ipc have been unified and simplified considerably.
      
      ------
      
      The way in which client contact the server has changed.
      
       - Server initializes its own margo instance and generate the endpoint
      communication string using `HG_Addr_self`.
       - This endpoint description string is written on the pid file
       - When the client library loads it will fetch the server endpoint
      description from the pid file and will use that to contact the server.
      c40be81b
  15. Oct 29, 2018
  16. May 11, 2018
  17. Mar 15, 2018
  18. Mar 07, 2018
    • Marc Vef's avatar
      Restructuring directory hierarchy of the project + re-adding header files to CMake sources. · 138e04ca
      Marc Vef authored
      - Previously the directory hierarchy was not clear regarding to which
        file belong to which part of the project (client or daemon).
        Further, we will have other clients in the future (such as Fuse).
      - CMake files now differentiate between include dirs for all targets
        and target specific ones.
      - Removed duplicate -pg flag.
      - Not listing header files when adding executables or libraries
        is considered bad practice. Note that include_directories() is adding
        include paths to the code while adding all files used for executables
        and libraries provide the context which files belong to each binary.
        When only include_directories() is set, CMake assumes that all files
        belong to a binary (which is not necessarily true). As a result,
        some IDEs may break as the do not support this assumption.
      
        In general we should almost always favor explicitness over implicitness.
      138e04ca
  19. Nov 29, 2017
  20. Nov 14, 2017
  21. Oct 13, 2017