Changes for CA-196882, FileSR and GC changes #295
Conversation
MarkSymsCtx
force-pushed
the
CA-196882
branch
from
9decdde
to
1e42e35
Compare
MarkSymsCtx
force-pushed
the
CA-196882
branch
from
87cffdc
to
400e790
Compare
| @@ -2752,7 +2771,7 @@ def should_preempt(session, srUuid): | |||
| if len(entries) == 0: | |||
| return False | |||
| elif len(entries) > 1: | |||
| raise util.SMException("More than one coalesce entry: " + entries) | |||
| raise util.SMException("More than one coalesce entry: " + len(entries)) | |||
There was a problem hiding this comment.
I think the purpose of the old code was to list the entries, not just report the number
There was a problem hiding this comment.
Update to replace len with str.
|
Apart from this, code is fine |
MarkSymsCtx
force-pushed
the
CA-196882
branch
2 times, most recently
from
87cffdc
to
74609b1
Compare
| @@ -2741,8 +2760,8 @@ def get_state(srUuid): | |||
| locking. | |||
| """ | |||
| init(srUuid) | |||
| if lockRunning.acquireNoblock(): | |||
| lockRunning.release() | |||
| if lockActive.acquireNoblock(): | |||
There was a problem hiding this comment.
This change was not here in the previous version.
What do we want to tell the user: if it is spawned or actively running?
There was a problem hiding this comment.
Spawned, this was in the patch queue but missed from the push. This is what caused the BVT to fail in the first submission.
MarkSymsCtx
force-pushed
the
CA-196882
branch
from
74609b1
to
87cffdc
Compare
|
About the commit message: I appreciate it is the squash of the two previous commits but the Let's find a one line title that captures the nature of the fix. Something like "GC in batch mode and deletes done immediately in SRs", for example. |
MarkSymsCtx
force-pushed
the
CA-196882
branch
from
87cffdc
to
a8be75f
Compare
FileSR performs VDI.delete inline Inline delete VDIs for LVHD SRs GC waits five minutes after start before initiating work loop. Use two locks in gcLoop, one to prevent multiple GC processs starting and one to interlink with abort requests while work is actually occuring. Inline delete orphaned nodes in coalesce After handling garbage in the GC loop proceed to coalesce without returning to scan and potentially finding more garbage whcih then prevents coalesce. Fix bug in _kickGC where the running GC could be stopped but not start a new one. Signed-off-by: Mark Syms <mark.syms@citrix.com>
MarkSymsCtx
force-pushed
the
CA-196882
branch
from
a8be75f
to
6152583
Compare
FileSR performs VDI.delete inline Inline delete VDIs for LVHD SRs GC waits five minutes after start before initiating work loop. Use two locks in gcLoop, one to prevent multiple GC processs starting and one to interlink with abort requests while work is actually occuring. Inline delete orphaned nodes in coalesce After handling garbage in the GC loop proceed to coalesce without returning to scan and potentially finding more garbage whcih then prevents coalesce. Fix bug in _kickGC where the running GC could be stopped but not start a new one. Reviewed-by: Germano Percossi <germano.percossi@citrix.com> GitHub: closes xapi-project#295
GC in batch mode and deletes done immediately in SRs
FileSR performs VDI.delete inline
Inline delete VDIs for LVHD SRs
GC waits five minutes after start before initiating work loop.
Use two locks in gcLoop, one to prevent multiple GC processs starting
and one to interlink with abort requests while work is actually occuring.
Inline delete orphaned nodes in coalesce
After handling garbage in the GC loop proceed to coalesce without returning
to scan and potentially finding more garbage whcih then prevents coalesce.
Fix bug in _kickGC where the running GC could be stopped but not start
a new one.
Signed-off-by: Mark Syms mark.syms@citrix.com