Skip to content
  1. Jan 28, 2021
  2. Dec 18, 2020
    • Marc Vef's avatar
      Merge branch '108-add-path-resolution-tests' into 'master' · 460cabe0
      Marc Vef authored
      Resolve "Add path resolution tests"
      
      Closes #108
      
      See merge request hpc/gekkofs!48
      460cabe0
    • Ramon Nou's avatar
      Reformat util/integration/gkfs.io files · 7a7f2cd1
      Ramon Nou authored and Marc Vef's avatar Marc Vef committed
      7a7f2cd1
    • Ramon Nou's avatar
      Added path_resolution test · 554f0e2c
      Ramon Nou authored and Marc Vef's avatar Marc Vef committed
      554f0e2c
    • Alberto Miranda's avatar
      Merge branch '94-remove-exist-check-when-creating-a-file' into 'master' · 28041105
      Alberto Miranda authored
      Optimization of create, stat, and remove operations. The following changes have been made:
      
      - `gkfs_open()` logic refactored.
      - create: Previously a stat RPC was send before each create to make sure the file doesn't exist. This logic is now implicit in the create operation on the daemon side.
      - `get_metadata()` was used on the client for all stat operation, creating a `shared_ptr` for the `Metadata` object in the process which was not needed. A new function `get_metadata_attr()` was created to only return the metadata binary string, which will only create the metadata object if actually required.
      - Remove logic was separated into two operations: `remove_metadata()` and `remove_data()`. 
      - `gkfs::config::metadata::implicit_data_removal` setting: If `true`, will remove data on the same node during the `remove_metadata()` RPC. This is mainly an optimization, but will be useful for future asynchronous removal implementations.
      
      Previously, the code path looked like this:
      1. `stat()` to get `size` and `mode`.
      2. Use these fields to determine if data needs to be removed or just metadata.
      3. `remove()` is called which, first, sends a single RPC to the daemon with the metadata. Afterwards, data is removed.
      4. The daemon used one handler for both cases.
      
      It now looks like this: 
      1. `remove()` is called which, first, sends a single RPC to the daemon with the metadata. Before, removing the metadata, the daemon fetches `mode` and `size`. If `implicit_data_removal` is set as a configuration, the data is removed in this RPC as well. `mode` and `size` are returned to the client.
      2. The client determines if data needs to be removed as well.
      3. If yes, sends a `remove_data()` RPC as it was previously.
      
      Depends on !66 and !74.
      
      Closes #94
      
      See merge request !60
      28041105
  3. Dec 17, 2020
  4. Dec 14, 2020
  5. Dec 11, 2020
  6. Dec 10, 2020
  7. Dec 09, 2020