From bab7d77cdd1d6c74787bcc7621315db29af247dc Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 7 Oct 2015 11:03:15 -0400 Subject: analysis of some topologies, and idea to generate moves --- ...rent_drop--from_presence_checking_failures.mdwn | 25 ++++++++++++++++++++++ 1 file changed, 25 insertions(+) (limited to 'doc') diff --git a/doc/bugs/concurrent_drop--from_presence_checking_failures.mdwn b/doc/bugs/concurrent_drop--from_presence_checking_failures.mdwn index c7df1b330..997c845f2 100644 --- a/doc/bugs/concurrent_drop--from_presence_checking_failures.mdwn +++ b/doc/bugs/concurrent_drop--from_presence_checking_failures.mdwn @@ -137,3 +137,28 @@ content from C to B, and then drop it from B. Need to consider whether this might cause currently working topologies with the assistant/sync --content to no longer work. Eg, might content pile up in a transfer remote? + +> The assistant checks after any transfer of an object if it should drop +> it from anywhere. So, it gets/puts, and later drops. +> Similarly, for sync --content, it first gets, then puts, and finally drops. + +> When dropping an object from remotes(s) + local, in `handleDropsFrom`, +> it drops from local first. So, this would cause content pile-up unless +> changed. +> +> Also, when numcopies > 1, a toplogy like +> `A(transfer) -- B(client) -- specials(backup)` would never be able to drop +> the file from A, because the specials don't support locking and it can't +> guarantee the content will remain on them. +> +> One solution might be to make sync --content/the assistant generate +> move operations, which can then ignore numcopies (like `move` does). +> So, move from A to B and then copy to the specials. +> +> Using moves does lead to a decrease in robustness. For example, in +> the topology `A(transfer) -- B(client) -- C (backup)`, with numcopies=2, +> and C intermittently connected, the current +> behavior with sync --content/assistant is for an object to reach B +> and then later C, and only then be removed from A. +> If moves were used, the object moves from A to B, and so there's only +> 1 copy instead of the 2 as before, in the interim until C gets connected. -- cgit v1.2.3