On Tue, May 22, 2012 at 9:52 AM, Saint Germain <span dir="ltr"><<a href="mailto:saintger@gmail.com" target="_blank">saintger@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 22 May 2012 17:44, Shawn Willden <<a href="mailto:shawn@willden.org">shawn@willden.org</a>> wrote:<br>
>> If I have my computer at home and a remote server somewhere, I want to<br>
>> use 1-out-of-2 configuration in case I lost either of them.<br>
><br>
> If you can maintain pretty high uptime and contribute at least 500 GB, you<br>
> might consider joining VolunteerGrid2.  Then instead of 1 of 2 you can do,<br>
> say, 10 of 20.  Or 15 of 20.<br>
><br>
<br>
</div>Interesting. However I really don't need this level of redundancy,<br>
pictures of me are not so critical ;-)<br></blockquote><div><br></div><div>:-)</div><div><br></div><div>A less-obvious implication is that 1-of-2 requires doubling the size of your files to store them, while 15-of-20 increases their size by only 33%.  If we had 40 nodes, you could do 35-of-40 and "waste" only 14%.  While storage is cheap enough that none of that matters, the impact on bandwidth is quantitatively the same and qualitatively more important.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
>> So tahoe-LAFS works in that case basically as Dropbox synchronisation<br>
>> (with the encryption).<br>
>> Is there some kind of optimization which only transfer modified parts<br>
>> to the other nodes, or is the whole file transfer each time it is<br>
>> modified ? Especially for VM.<br>
><br>
> It's whole-file.<br>
><br>
<br>
</div>Ok, definitely a problem for VM then.<br></blockquote><div><br></div><div>Probably.  I can think of some workarounds, such as snapshotting your VMs, which causes changes to be written to a small differences file leaving the bulk of the virtual storage unmodified.  But, no, Tahoe isn't particularly well suited to backing up large files.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">>> Same question for moved files.<br>
><br>
> Moved files are not re-uploaded.  As long as the content is the same, Tahoe<br>
> will recognize that the file is already in the grid.<br>
<br>
</div>Ok good for movies, pictures and mp3 then.<br></blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">>> If I have a VM of 1 Go that I want to regularly backup on the remote<br>
>> server. Do I get to use 1 Go on the home computer and 1 Go on the<br>
>> remote computer for the current version and 1 Go for each backup of<br>
>> the VM ?<br>
><br>
> I don't understand what you mean by "1 Go".<br>
><br>
<br>
</div>Giga-octets. Sorry 1 Gigabyte then.</blockquote><div><br></div><div>Interesting.  That's not an abbreviation I've seen.</div><div><br></div><div>Each file you back up is split into N pieces, each of 1/K size, and distributed to the servers in your grid.  So if you have a 1 GB VM on your desktop machine and you have two servers in your grid,  and K=1, N=2, Tahoe will split your VM into two pieces, each 1/1 = 1 x 1 GB in size and store one in each of your servers, for a total of 2 GB stored to back up the VM.</div>
<div><br></div><div>Or for K=15, N=20, that would be 20 pieces, each 1/15 = .067 * 1 GB = 67 MB in size, for a total of 1.3 GB stored to back up the VM. :-)</div></div><div><br></div>-- <br>Shawn<br>