On 13 Sep 2018 at 14:43, Roberto Ragusa wrote:

Subject:                Re: OT: fastest way to copy one drive to another
To:                     users@lists.fedoraproject.org
From:                   Roberto Ragusa <m...@robertoragusa.it>
Date sent:              Thu, 13 Sep 2018 14:43:51 +0200
Send reply to:          Community support for Fedora users 
<users@lists.fedoraproject.org>

> On 09/08/2018 01:34 PM, Michael D. Setzer II wrote:
> 
> > It is a c program that was included with g4l when I took it over, but then 
> > I 
> > rewrote it to do only what was actually used by the project.
> > 
> > It's included with the complete source code on sourceforge with the project 
> > source.
> 
> This is useful and may be worth a separate standalone package.
> 
> I usually use "pv" for pipe progress output.
> It apparently has buffer size option too, I'm discovering just now.

Wasn't aware of that program, and it seems to work with dialog.
Only issue I have, is that it is over 60+K in size, while the jetcat-mod is 
about 
8.5K. Since it is only working in ram, testing didn't show improvement making 
buffers larger, so use a 1M with the dd. Since once the disk buffer is full, it 
stays that way for most of the process. Perhaps with newer disks a larger 
buffer might increase speed a little.


jetcat-mod outputs lines ever 5 seconds by the option used, and has the 
format used by the dialog progress bar. G4L is using the dialog menu system 
along with the script for processing.
An output line looks like this.

47.16%       4044.00MB of 8574.67MB     time: 0:01:13  55.40MB/sec

For the progress bar the first number is the critical part, rest is just 
displayed 
to show progress so far of the total size, elapsed time so far, and the 
calculated speed so far. With options that have compression, this can greatly 
increase the effective speed if unused space has been zeroed out.

With Fedora Core 3 long ago. Did a clean install on an 80G disk, and then 
did an image and it was 12G in sized. Cleared the unused space and redid 
image, and it dropped size to 2.5G.  Unused space with random data is still 
backed up and doesn't compress well.

Thanks for the info.

> 
> Regards.
> 
> -- 
>    Roberto Ragusa    mail at robertoragusa.it
> _______________________________________________
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org


+------------------------------------------------------------+
 Michael D. Setzer II - Computer Science Instructor (Retired)     
 mailto:mi...@guam.net                            
 mailto:msetze...@gmail.com
 Guam - Where America's Day Begins                        
 G4L Disk Imaging Project maintainer 
 http://sourceforge.net/projects/g4l/
+------------------------------------------------------------+

http://setiathome.berkeley.edu (Original)
Number of Seti Units Returned:  19,471
Processing time:  32 years, 290 days, 12 hours, 58 minutes
(Total Hours: 287,489)

BOINC@HOME CREDITS

ROSETTA      65786414.038490 | ABC          16613838.513356
SETI        109526605.084600 | EINSTEIN    141382979.499240
_______________________________________________
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Reply via email to