NFS Ganesha List Archives
Sign In Sign Up
Manage this list Sign In Sign Up

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

Devel

Thread Start a new thread
Download
Threads by month
  • ----- 2026 -----
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2025 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2021 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2020 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2019 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2018 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
devel@lists.nfs-ganesha.org

October 2018

  • 24 participants
  • 119 discussions
Change in ffilz/nfs-ganesha[next]: NFSv4: convert nfs4_op_lock to sticky grace period
by GerritHub 04 Oct '18

04 Oct '18
From Jeff Layton <jlayton(a)redhat.com>: Jeff Layton has uploaded this change for review. ( https://review.gerrithub.io/428019 Change subject: NFSv4: convert nfs4_op_lock to sticky grace period ...................................................................... NFSv4: convert nfs4_op_lock to sticky grace period This also reorganizes the grace period checking logic to better handle taking a grace period reference. Change-Id: Ia347c987a7cd79210fb333a90fdec9f2bb22113f Signed-off-by: Jeff Layton <jlayton(a)redhat.com> --- M src/Protocols/NFS/nfs4_op_lock.c 1 file changed, 31 insertions(+), 26 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/19/428019/1 -- To view, visit https://review.gerrithub.io/428019 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: Ia347c987a7cd79210fb333a90fdec9f2bb22113f Gerrit-Change-Number: 428019 Gerrit-PatchSet: 1 Gerrit-Owner: Jeff Layton <jlayton(a)redhat.com>
1 0
0 0
Change in ffilz/nfs-ganesha[next]: NFS: convert nfs3_setattr to sticky grace period
by GerritHub 04 Oct '18

04 Oct '18
From Jeff Layton <jlayton(a)redhat.com>: Jeff Layton has uploaded this change for review. ( https://review.gerrithub.io/428018 Change subject: NFS: convert nfs3_setattr to sticky grace period ...................................................................... NFS: convert nfs3_setattr to sticky grace period This means that we now check for the grace period a bit later. Change-Id: Id082d97e7375529cd0d8a5f2aab3a5a41fa2b785 Signed-off-by: Jeff Layton <jlayton(a)redhat.com> --- M src/Protocols/NFS/nfs3_setattr.c 1 file changed, 14 insertions(+), 13 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/18/428018/1 -- To view, visit https://review.gerrithub.io/428018 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: Id082d97e7375529cd0d8a5f2aab3a5a41fa2b785 Gerrit-Change-Number: 428018 Gerrit-PatchSet: 1 Gerrit-Owner: Jeff Layton <jlayton(a)redhat.com>
1 0
0 0
Change in ffilz/nfs-ganesha[next]: 9p: take a sticky grace reference for lock ops
by GerritHub 04 Oct '18

04 Oct '18
From Jeff Layton <jlayton(a)redhat.com>: Jeff Layton has uploaded this change for review. ( https://review.gerrithub.io/428017 Change subject: 9p: take a sticky grace reference for lock ops ...................................................................... 9p: take a sticky grace reference for lock ops Change-Id: Idb09b2e9c1c0e87b9b094671062be4cc9d6457d2 Signed-off-by: Jeff Layton <jlayton(a)redhat.com> --- M src/Protocols/9P/9p_lock.c 1 file changed, 2 insertions(+), 1 deletion(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/17/428017/1 -- To view, visit https://review.gerrithub.io/428017 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: Idb09b2e9c1c0e87b9b094671062be4cc9d6457d2 Gerrit-Change-Number: 428017 Gerrit-PatchSet: 1 Gerrit-Owner: Jeff Layton <jlayton(a)redhat.com>
1 0
0 0
Change in ffilz/nfs-ganesha[next]: SAL: sticky grace periods
by GerritHub 04 Oct '18

04 Oct '18
From Jeff Layton <jlayton(a)redhat.com>: Jeff Layton has uploaded this change for review. ( https://review.gerrithub.io/428016 Change subject: SAL: sticky grace periods ...................................................................... SAL: sticky grace periods Some operations require a grace period, or that we not be in one. Ganesha will generally check this prior to doing the operation, but those checks are racy. We could end up flipping the state of grace after checking but during or before the actual operation. This is particularly a problem for clustered servers that may end up going back into grace to satisfy the needs of another node, as they could end up reporting that they are enforcing the grace period while there are still ops in flight. This patch adds some new grace period handling infrastructure to address this. When ganesha needs to do an operation that requires a particular state of grace, take a reference to that state to ensure that it can't change until we are done. If we go to start or lift the grace period, check first to see whether there might be ops in flight. If there are, then set a flag indicating that a change has been requested and don't do it. If that flag is set, then we will no longer hand out grace period references. Once the refcount goes to zero, we can allow the change to occur and clear the flag so that new references can be acquired again. We start by changing the usage of current_grace. It still contains when the most recent grace period expires, but we don't use the value of 0 to denote anything special now. The other values are now tracked in a single uint32_t, which contains two bitflags and a counter. By doing it this way, we can handle the most common usage (getting/putting references) locklessly. Starting or lifting the grace period still requires the grace_mutex however. Change-Id: I7089cb468baaa64e98cc9c6220c009fc61c85840 Signed-off-by: Jeff Layton <jlayton(a)redhat.com> --- M src/SAL/nfs4_recovery.c M src/include/sal_functions.h 2 files changed, 151 insertions(+), 14 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/16/428016/1 -- To view, visit https://review.gerrithub.io/428016 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: I7089cb468baaa64e98cc9c6220c009fc61c85840 Gerrit-Change-Number: 428016 Gerrit-PatchSet: 1 Gerrit-Owner: Jeff Layton <jlayton(a)redhat.com>
1 0
0 0
Change in ffilz/nfs-ganesha[next]: SAL: decrement reclaim_completes counter when expiring client
by GerritHub 04 Oct '18

04 Oct '18
From Jeff Layton <jlayton(a)redhat.com>: Jeff Layton has uploaded this change for review. ( https://review.gerrithub.io/428012 Change subject: SAL: decrement reclaim_completes counter when expiring client ...................................................................... SAL: decrement reclaim_completes counter when expiring client A client could send a RECLAIM_COMPLETE and then end up reestablishing the clientid during the grace period, and then send another one. If that happens we'll expire the old client, but the reclaim_completes counter will be artificially high. Ensure we decrement reclaim_completes when expiring a client that has sent one. Change-Id: I046a95e320c9fed2ae887eab3056f95ff4ab7951 Signed-off-by: Jeff Layton <jlayton(a)redhat.com> --- M src/SAL/nfs4_clientid.c M src/SAL/nfs4_recovery.c M src/include/sal_functions.h 3 files changed, 6 insertions(+), 1 deletion(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/12/428012/1 -- To view, visit https://review.gerrithub.io/428012 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: I046a95e320c9fed2ae887eab3056f95ff4ab7951 Gerrit-Change-Number: 428012 Gerrit-PatchSet: 1 Gerrit-Owner: Jeff Layton <jlayton(a)redhat.com>
1 0
0 0
Change in ffilz/nfs-ganesha[next]: Create 9P worker threads only if 9P is configured
by GerritHub 04 Oct '18

04 Oct '18
From Malahal <malahal(a)gmail.com>: Malahal has uploaded this change for review. ( https://review.gerrithub.io/427980 Change subject: Create 9P worker threads only if 9P is configured ...................................................................... Create 9P worker threads only if 9P is configured Currently we create 9P socket and 9P dispatcher thread only if 9P protocol is configured. No need for worker threads without the dispatcher thread, so these are also created only if 9P protocol is configured. Change-Id: I585a645b79c580ef420a867244dab3be22c48148 Signed-off-by: Malahal Naineni <malahal(a)us.ibm.com> --- M src/MainNFSD/nfs_init.c 1 file changed, 8 insertions(+), 7 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/80/427980/1 -- To view, visit https://review.gerrithub.io/427980 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: I585a645b79c580ef420a867244dab3be22c48148 Gerrit-Change-Number: 427980 Gerrit-PatchSet: 1 Gerrit-Owner: Malahal <malahal(a)gmail.com>
1 0
0 0
Change in ffilz/nfs-ganesha[next]: Free group name string properly in proc_export()
by GerritHub 03 Oct '18

03 Oct '18
From Malahal <malahal(a)gmail.com>: Malahal has uploaded this change for review. ( https://review.gerrithub.io/427946 Change subject: Free group name string properly in proc_export() ...................................................................... Free group name string properly in proc_export() If there is a client block with CIDR spec but the last client block is not a CIDR spec, then the code will try to free unallocated memory leading to a crash! Also, there is a memory leak if there are multiple client blocks with CIDR spec. Each client block with CIDR spec needs to free group name string. Change-Id: I46d4a78d7a6a88f7374e547d59549f098cf1dfcd Signed-off-by: Malahal Naineni <malahal(a)us.ibm.com> --- M src/Protocols/NFS/mnt_Export.c 1 file changed, 4 insertions(+), 4 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/46/427946/1 -- To view, visit https://review.gerrithub.io/427946 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: I46d4a78d7a6a88f7374e547d59549f098cf1dfcd Gerrit-Change-Number: 427946 Gerrit-PatchSet: 1 Gerrit-Owner: Malahal <malahal(a)gmail.com>
1 0
0 0
Change in ffilz/nfs-ganesha[next]: NFS4: don't set cid_server_owner more than once
by GerritHub 03 Oct '18

03 Oct '18
From Jeff Layton <jlayton(a)redhat.com>: Jeff Layton has uploaded this change for review. ( https://review.gerrithub.io/427914 Change subject: NFS4: don't set cid_server_owner more than once ...................................................................... NFS4: don't set cid_server_owner more than once We already set the thing on entry into the function. There is no need to do it on every EXCHANGE_ID. Change-Id: I0dcce69985cc94fa5e950ac269cebc59b38207aa Signed-off-by: Jeff Layton <jlayton(a)redhat.com> --- M src/Protocols/NFS/nfs4_op_exchange_id.c 1 file changed, 0 insertions(+), 10 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/14/427914/1 -- To view, visit https://review.gerrithub.io/427914 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: I0dcce69985cc94fa5e950ac269cebc59b38207aa Gerrit-Change-Number: 427914 Gerrit-PatchSet: 1 Gerrit-Owner: Jeff Layton <jlayton(a)redhat.com>
1 0
0 0
Change in ffilz/nfs-ganesha[next]: MDCACHE - Fix readdir chunking when reloading chunks
by GerritHub 02 Oct '18

02 Oct '18
From Daniel Gryniewicz <dang(a)redhat.com>: Daniel Gryniewicz has uploaded this change for review. ( https://review.gerrithub.io/427787 Change subject: MDCACHE - Fix readdir chunking when reloading chunks ...................................................................... MDCACHE - Fix readdir chunking when reloading chunks - Track the first and last chunks in a readdir cycle in the readdir state; this allows reloading the first chunk. - Track the CK used to reload a chunk. We can't use the first CK, since that will load the second entry in the chunk. - When we reload a chunk, skip all the entries in that chunk we already returned to the caller, to avoid duplicate dirents. Change-Id: I2a85036aa6a93a773a37d174056c3e1aa764f6bb Signed-off-by: Daniel Gryniewicz <dang(a)redhat.com> --- M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_int.h M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c 3 files changed, 48 insertions(+), 19 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/87/427787/1 -- To view, visit https://review.gerrithub.io/427787 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: I2a85036aa6a93a773a37d174056c3e1aa764f6bb Gerrit-Change-Number: 427787 Gerrit-PatchSet: 1 Gerrit-Owner: Daniel Gryniewicz <dang(a)redhat.com>
1 0
0 0
Change in ffilz/nfs-ganesha[next]: MDCACHE - Update tracepoints to print obj_handle
by GerritHub 02 Oct '18

02 Oct '18
From Daniel Gryniewicz <dang(a)redhat.com>: Daniel Gryniewicz has uploaded this change for review. ( https://review.gerrithub.io/427786 Change subject: MDCACHE - Update tracepoints to print obj_handle ...................................................................... MDCACHE - Update tracepoints to print obj_handle Correlating tracepoints inside and outside MDCACHE is difficult when MDCACHE traces the entry, which is invisible outside MDCACHE. Instead, trace the obj_handle, which is what other modules would trace. Change-Id: Ie42c992033cdd0046cd9aa52f73760370a46ee4f Signed-off-by: Daniel Gryniewicz <dang(a)redhat.com> --- M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_hash.h M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c M src/include/gsh_lttng/mdcache.h 4 files changed, 55 insertions(+), 51 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/86/427786/1 -- To view, visit https://review.gerrithub.io/427786 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: Ie42c992033cdd0046cd9aa52f73760370a46ee4f Gerrit-Change-Number: 427786 Gerrit-PatchSet: 1 Gerrit-Owner: Daniel Gryniewicz <dang(a)redhat.com>
1 0
0 0
  • ← Newer
  • 1
  • ...
  • 8
  • 9
  • 10
  • 11
  • 12
  • Older →

HyperKitty Powered by HyperKitty version 1.3.12.