1. 14 Apr, 2020 2 commits
  2. 07 Apr, 2020 1 commit
  3. 01 Apr, 2020 2 commits
  4. 30 Mar, 2020 1 commit
  5. 26 Mar, 2020 1 commit
  6. 12 Mar, 2020 4 commits
  7. 02 Mar, 2020 3 commits
  8. 18 Feb, 2020 1 commit
  9. 13 Feb, 2020 2 commits
  10. 29 Jan, 2020 1 commit
  11. 06 Dec, 2019 1 commit
  12. 29 Nov, 2019 2 commits
  13. 15 Nov, 2019 2 commits
  14. 11 Nov, 2019 1 commit
  15. 23 Oct, 2019 3 commits
  16. 08 Oct, 2019 1 commit
  17. 23 Sep, 2019 1 commit
  18. 20 Sep, 2019 1 commit
  19. 13 Sep, 2019 2 commits
  20. 04 Sep, 2019 2 commits
  21. 20 Aug, 2019 2 commits
  22. 13 Aug, 2019 1 commit
  23. 26 Jul, 2019 1 commit
    • Eric Cano's avatar
      #533 Changed strategy for implementation. · 6385126d
      Eric Cano authored
      Moved the space reservation information to the DriveStatus object store object instead of a new central registry.
      The central registry would have been a single point of contention as was the DriveRegistry before being split into
      DriveStates. As the problem is so close to the one of the drive status, we can actually reuse the drive status for this purpose.
      
      The algorithm will also change as we move the responsibility of querying the free space from the disk systems into the OStoreDb
      object instead of the Scheduler. This leads to a slightly worth layering of responsibilities, making the OStoreDb::RetrieveMount
      object a client of the disk::DiskSystemFreeSpaceList object.
      
      The current implementation will also query the free space from the disk systems on each pop, instead of doing so in a globally
      cached fashion. With the new model, we could cache the free space per drive (if needed), but not globally. This is not expected
      to be a real issue and free space is a global counter in the disk system, expected to be readily available.
      6385126d
  24. 25 Jul, 2019 2 commits