1. 03 Nov, 2020 2 commits
  2. 12 Dec, 2019 1 commit
    • Patrick Farrell's avatar
      LU-11670 osc: glimpse - search for active lock · 2548cb9e
      Patrick Farrell authored
      When there are lock-ahead write locks on a file, the server
      sends one glimpse AST RPC to each client having such (it
      may have many) locks. This callback is sent to the lock
      having the highest offset.
      
      Client's glimpse callback goes up to the clio layers and
      gets the global (not lock-specific) view of size.  The clio
      layers are connected to the extent lock through the
      l_ast_data (which points to the OSC object).
      
      Speculative locks (AGL, lockahead) do not have l_ast_data
      initialised until an IO happens under the lock. Thus, some
      speculative locks may not have l_ast_data initialized.
      
      It is possible for the client to do a write using one lock
      (changing file size), but for the glimpse AST to be sent to
      another lock without l_ast_data initialized.  Currently, a
      lock with no l_ast_data set returns ELDLM_NO_LOCK_DATA to
      the server.  In this case, this means we do not return the
      updated size.
      
      The solution is to search the granted lock tree for any lock
      with initialized l_ast_data (it points to the OSC object
      which is the same for all the extent locks) and to reach the
      clio layers for the size through this lock instead.
      
      Lustre-change: https://review.whamcloud.com/33660
      Lustre-commit: b3461d11
      
      
      
      cray-bug-id: LUS-6747
      Signed-off-by: default avatarPatrick Farrell <pfarrell@whamcloud.com>
      Change-Id: I6c60f4133154a3d6652315f155af24bbc5752dd2
      Reviewed-by: default avatarAndreas Dilger <adilger@whamcloud.com>
      Reviewed-by: default avatarBobi Jam <bobijam@hotmail.com>
      Signed-off-by: default avatarMinh Diep <mdiep@whamcloud.com>
      Reviewed-on: https://review.whamcloud.com/36406
      
      Tested-by: default avatarjenkins <devops@whamcloud.com>
      Tested-by: default avatarMaloo <maloo@whamcloud.com>
      Reviewed-by: default avatarOleg Drokin <green@whamcloud.com>
      2548cb9e
  3. 21 Nov, 2019 1 commit
  4. 12 Sep, 2019 1 commit
  5. 25 Jun, 2019 1 commit
  6. 20 Jun, 2019 1 commit
  7. 01 Apr, 2019 1 commit
  8. 17 Nov, 2018 1 commit
  9. 23 Oct, 2018 1 commit
  10. 10 Oct, 2018 1 commit
  11. 05 Oct, 2018 1 commit
  12. 18 Aug, 2018 1 commit
  13. 29 May, 2018 1 commit
  14. 17 May, 2018 1 commit
  15. 06 May, 2018 1 commit
  16. 19 Apr, 2018 1 commit
  17. 09 Apr, 2018 1 commit
  18. 20 Jan, 2018 1 commit
  19. 09 Jan, 2018 1 commit
  20. 15 Nov, 2017 1 commit
  21. 01 Nov, 2017 1 commit
  22. 21 Oct, 2017 1 commit
  23. 17 Oct, 2017 1 commit
  24. 21 Sep, 2017 2 commits
    • James Simmons's avatar
      LU-8541 ldlm: don't use jiffies as sysfs parameter · 800ffd47
      James Simmons authored
      
      
      The ldlm sysfs file handles lru_max_age in jiffies which is wrong
      since jiffies are not consistent across machine since HZ is
      configurable at compile time. Talking to most users they thought
      lru_max_age was in seconds which is incorrect. The best way to
      fix this is to move lru_max_age to millisecs since most systems
      lustre deals with sets HZ to 1000. To make it clear it is in
      milliseconds print out lru_max_age with "ms". Since users tend
      to think in seconds allow passing in seconds besides milliseconds
      and internally converting them to nanaseconds. Since we have to
      support milliseconds move to ktime_t since we can't use time64_t.
      Unfortunately, this makes a relatively large patch, but I could
      not find a way to split it up some more without breaking atomicity
      of the change.
      
      Change-Id: I0b1814fd9d903767f62fe141d2c95845b75fb95a
      Signed-off-by: default avatarJames Simmons <uja.ornl@yahoo.com>
      Reviewed-on: https://review.whamcloud.com/28370
      
      Reviewed-by: default avatarAndreas Dilger <andreas.dilger@intel.com>
      Tested-by: Jenkins
      Tested-by: default avatarMaloo <hpdd-maloo@intel.com>
      Reviewed-by: default avatarDmitry Eremin <dmitry.eremin@intel.com>
      Reviewed-by: default avatarOleg Drokin <oleg.drokin@intel.com>
      800ffd47
    • Patrick Farrell's avatar
      LU-6179 llite: Implement ladvise lockahead · a8dcf372
      Patrick Farrell authored
      Ladvise lockahead is a new feature allowing userspace to
      request extent locks in advance of the IO which will use
      them. These locks are not expanded beyond the size
      requested by userspace.  They are intended to make it
      possible to address lock contention between multiple
      clients resulting from lock expansion.  They should allow
      optimizing various IO patterns, notably strided writing.
      (Further information in LU-6179)
      
      Asynchronous glimpse locks are a speculative version of
      glimpse locks, and already implement the required behavior.
      Lockahead requests share this behavior.
      
      Additionally, lockahead creates extent locks in advance
      of IO, and so breaks the assumption that the holder of the
      highest lock knows the current file size.
      
      So we also modify the ofd_intent_policy code to glimpse
      PW locks until it finds one it knows to be in use, taking
      care to send only one glimpse to each client.
      
      The current patch allows asynchronous non-blocking lock
      ahead requests and synch...
      a8dcf372
  25. 29 Jul, 2017 1 commit
  26. 19 Jul, 2017 1 commit
  27. 19 Jun, 2017 1 commit
  28. 09 May, 2017 1 commit
  29. 14 Mar, 2017 1 commit
  30. 09 Mar, 2017 1 commit
  31. 17 Dec, 2016 1 commit
  32. 28 Oct, 2016 1 commit
  33. 08 Oct, 2016 1 commit
  34. 22 Aug, 2016 1 commit
  35. 20 Jul, 2016 1 commit
  36. 27 Jun, 2016 1 commit
  37. 20 Jun, 2016 1 commit
  38. 14 Jun, 2016 1 commit