Hi … from a .syncthing.file.tmp ?
Unless temp indexes have been disabled (that’s an advanced config option somewhere), yes.
1 Like
Per folder 
. Wonderful
Does the “File Pull Order” setting applies to blocks too ? I mean … something that means nothing. The good question is : are blocks spread/fetched randomly ?
Hmmmm, it seems only nodes that have the full file send blocks: I gave a try with a 1Gig file:
A sends 500M to B (1MB/s)
Fireup C (starts syncing 500KB/s)
A pauses C
C shows “out of sync” and receives nothing
A pauses C to give all b/w to B so that file quickly nearly finishes
A resumes C
C syncs @ 500KB/s
B finalize file
C syncs @ 2MB/s
So B doesn’t send blocks when she hasn’t the whole file.
[EDIT] So we can say A’s U/L bandwidth is wasted when 2 nodes miss a file, as the node that has the whole file (A) may send the same block(s) to both B & C before one of these two is able to send them to the third.
Block order is randomized, so until C has enough blocks to win the random lottery it’s not used. If any of the blocks B wants is not available, the whole thing aborts, regardless that C has “some” blocks it might want.
Decision of which A or C should be used when fetching a block is decided by picking the one with least requests in flight.
A better test would probably be if you had per device limits, limiting A to B to 500kbps and B to C being unlimited, and A to C being like 2MBps, then you’d see more and more requests from B going to C. Perhaps you can mimick that with IP tables.
I used the hard limit of UL of french ADSL ~1Mb/s in my test. The 3 nodes have roughly the same (and same roughly 20Mb/s DL).
A -> 1 single node @ 1Mb/s
A -> 2 nodes @ ~500kB/s each
A had the whole file from the biginning, and later B got 50-90% when C began syncing and I saw that C never DL’d at 2Mb/s rate before B had the whole file. ~1mn after B got the whole file, then only C reached 2Mb/s DL rate.
One 1GB file is roughly 8000 blocks isn’t it ?
The .tmp files are only available while they are worked on, if C stopped syncing the file from A (because A went away), the temporary blocks are no longer available.
You can enable STTRACE=model on C, and filter out REQ(out) to see where the requests are going. If ft=true, then it means it’s being fetched from a temporary file.
If you run syncthing in -verbose mode, you should see RemoteDownloadProgress events in the console, which would imply that the device is being notified about progress in the tmp file.
Also, B advertises what it has only once every 10 or so seconds.
Yes, 1GB is around 8k blocks.
Thank you Audrius for the directions. Later I checked on another setup where both B & C were on a same LAN (in the OP, all 3 nodes were remote to each other via WAN). In the 2nd check I didn’t even needed to use STTRACE as I could see C completion speed very fast, far quicker than A’s UL could allow, so there I could see C fetches from B. Nice.
I’ll check again the case where all 3 are on WAN to each other, an take care with your comment about temp blocks no more available. Do I understand correctly if I rephrase this way : blocks that yet were Dl’d by B from A become unavailable to C from B as soon as A goes away? Even the ones that C was aware available on B?
If I’m right, which one from B or C is responsible for this behaviour ? Any of the first that sees A went away ? Or is it a specific decision of block holder B that drops current transfers to C and further requests from C, or block requester C that drops current transfers from B and pending requests to B?
Blocks in temporary files are only available to others while the download is on-going, as soon as the download stops on C (due to A going away and nobody having that block that A shared), the blocks are no longer available to B.
Sorry to insist Audrius: when you say “the download”, do you mean the download of this very block being downloading, which makes sense as B would start to pull a block that may never end if the full block never comes back in the online cluster. My question is rather about blocks that already are in full status at several places in the cluster when the single full file source (A) goes away. In this case, will B go on downloading blocks he doesn’t have from C having them when A goes away?
A related precision is: can a single block be downloaded at the same time from more than one source, i.e pullers can co-operate to a single block building at the same time (if not, in no way this is a feature request)?
An other precision that will calmh down my curiosity: at a given time, A partially goes away from the cluster (e.g. A pauses B and keeps C resumed). At this very moment, A is the single 100% full file source, C completed say 50% of the file and B completed only 10%. From your first answer I deduce the random lottery on B may pick block(s) C doesn’t have and A can’t supply, of course, as being away from B p.o.v. . Then “the whole thing aborts”. the question is : when (if ever) will it restart ? Assumed A won’t resume B, will download on B only restart when C completes and announces the whole file? Or at some interval will B run a new random lottery on missing blocks and submit a request that C may fulfil in case C has these blocks? In the same time, will C go on informing B about his progress before file completion?
And for the end,
A now fully going away, still C being at 50% and B at 10%, does the quote above mean that block exchange between B and C definitively stops (until A comes back some way) and then the cluster will never stabilize to 50% ∪ 10% on both B and C (note I didn’t say 60% as I guess 50% on C and 10% on B may overlap).
Thank you for reading
So I haven’t even read the question in full as it’s very long and full of text decorations that makes it hard to read.
A block is downloaded only from one place at a time.
Blocks that X already have in .tmp file are only advertised to others while X itself is working on turning .tmp file to a full file. Once the pull stops (for whatever reason), the blocks are advertised as no longer available, and if the download succeeded will be replaced with an advertisement that the whole file is available.
Any device will abort the download as soon as it can’t find a device that has a block it’s trying to pull.
You could have two devices that have a tmp file each with separate sets of blocks that when put together make the whole file, in theory they should be able to finish the download from each other without the need of a device with the full file, yet in practice it rarely happens as available blocks in tmp file are advertised once every 10 seconds.
Thanks man, I feel this answers the whole. Really st is a great thing.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.