faster OS image download
Is your feature request related to a problem? Please describe
The full VM OS image download is slow from Australia, it took around 20 mins
Feature Request: Faster or Local OS load for (big) images
https://github.com/threefoldtech/test_feedback/issues/419
Describe the solution you'd like
There are two kind of solutions:
-
from hub side It is already described on https://git.ourworld.tf/tfgrid/circle_engineering/issues/33: create replica of flist hub that are closer to the users
-
speedup the download from
zossiderfsdownload the block onreadoperation. Because the download triggered byio.Copy(https://github.com/threefoldtech/zos/blob/0ea61706e1a501d4e774a9195c139e2995bdd1cb/pkg/storage/disk.go#L148-L152), the flow become something like this: - OS try to read some block -rfscall remotehubto download the block - repeat until finish The process happens sequentially, hence very slowSome alternatives: a. Do the download on
open, it is what happens in0-fsIMO It is quite a big change from architecture point of view, i currently don't know the impact of this change b. paralelize theio.CopyIt is a simple solution, but if the slowness happen on other usecase, we have to apply the same technique, which might be error prone.
While making hub replica would help to speedup the issue, i think solution 2.b also worth to do because it would further speedup the process and also quite easy to do.
I've tried to paralelize the io.Copy with this environment:
zosnode: In Indonesia, run on my old 2016 PC onqemu. (indonesia is close to Australia)- os image: nixos
the results:
- original
io.Copy: 1 hour (much worse than the reported 20 mins :) ) - 5 goroutines: 20 mins
- 10 goroutines: 20 mins
- 15 goroutines: 24 mins
While the number of speedup (in regards to number of goroutines) might be different for different locations, the goroutines is indeed speedup the process.
cc @xmonader @rawdaGastan @ashraffouda
this should be done from rfs side if needed