FOG Torrent
-
@Junkhacker Good point! Thanks for mentioning. Now more and more I remember why I totally dismissed torrent for imaging for me. I guess there is no way you could combine random block torrent transfer with partclone (filesystem aware) imaging that is writing to disk on the fly. Only raw would be possible. With current HDs being up to 1 TB and more even in clients this would be a huge wast of network traffic…
Reading through some old mails with a college I remembered the HD in the clients being a massive bottleneck as well. Disk IO literally dropped down to the floor as clients upload (read) and download (write) random blocks at the same time.
Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)
Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG
-
@Sebastian-Roth well, we could still shrink the partition to the size of the actual data usage like we do now. that would keep you from having 1 TB images unless there’s actually a TB of data on it. but you still couldn’t compress it, and it would be a torrent only image, you couldn’t do normal unicast/multicast deployments with it.
-
@Junkhacker What if a regular image was decompressed & then mounted on the FOG server, and then it’s raw data sent out via a torrent task ?
I still think that sticking the standard partition data at the end of the drive is perfectly acceptable. Torrent task type is made to overcome network issues, not HDD issues.
