unbalance icon indicating copy to clipboard operation
unbalance copied to clipboard

Speed as an average over time, percentage in bars, and moving rows.

Open iarp opened this issue 4 years ago • 2 comments

3 things I'm curious about.

  1. Is it possible to get a speed calculation over a shorter period of time rather than the average over the whole duration? As of currently I had dockers and vm's running on other disks which caused the first 4 hours to go at an average of 26MB/s. After I stopped those services, via bwm-ng which averages speed over a 30 second window i can see that its transferring at 41MB/s now. Meanwhile unbalance still shows 26.15MB/s (increasing 0.01MB/s very slowly) an hour after stopping docker/vm services and you can watch the time remaining countdown by 2 seconds instead of 1 second.
  2. Any possibility of a percentage calculation on the Progress bars? Or even a X/total number. I'm unsure how the percentage is already calculated so I wasn't sure which display would be simpler.
  3. Is it possible to move completed rows to the bottom so that the most active row and upcoming rows are at the top at all times?
  4. Stop after current. You've made a mistake and it's currently moving data. If you stop it using the current stop it kills rsync leaving duplicated data. A "Stop After Current" option would allow the current rsync to finish along with the deletion of source and then stops. Now everything remains clean.

iarp avatar Jan 18 '21 18:01 iarp

Hi,

In general, I don't have any spare cycles to work on unbalance right now, work taking precedence and all, mostly looking at urgent bugs if they come up.

In any case, regarding your questions

1 - Yes, it's possible to keep a short window, would need some changes though 2 - Progress bar measures transferred bytes vs total 3 - Yes, that sounds like a good idea 4 - I have to give it some thought, but I think it's possible

jbrodriguez avatar Jan 30 '21 16:01 jbrodriguez

Adding my 2cents, After seeing a drive slowly start to fail, I decided to offload all the data on it to better drives. As the move was occurring I hit a spot on the drive that dropped the move to a mere 1MB/s for a 14GB file, I thought it was stuck and the only indication that I saw that the process was still alive was the completed ticked up a .01% after 5 minutes. (I was moving 5TB of data). Having the ability to have output that is more granular on a per task basis would be helpful.

As for option 4 having come across this in my SI work, it comes down to logging and capturing the last file for the rsync and then rm’ing the file from the destination. It’s a pretty simple hack to do, but ALWAYS check to see in the source file still exists before deleting the destination :-P

mkruer avatar Feb 01 '21 03:02 mkruer