<div>
<div><span>The objective is to create a redundant system. Shouldn't gluster be writing on all 6 nodes simultaneously rather than sequentially? Else it would seem like a rather poor choice for highly redundant systems.<br>
</span></div><div>
<span>Regards<br>-- <br>David Pusch<br><br></span>
<p style="color: #a0a0a0;">On Mittwoch, 10. August 2011 at 14:37, Whit Blauvelt wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div>On Wed, Aug 10, 2011 at 02:22:55PM +0200, David Pusch wrote:<br><br><blockquote type="cite"><div>we now did another test where we mounted the Volume on the client and shut<br>down all Servers but one. We then transferred a 1 GB test file to the Volume.<br>The transfer took around 10 seconds. We then brought up another server from the<br>Cluster and again transferred a 1 GB file. Transfer time now was roughly 20<br>seconds. We proceeded in this manner for the last two servers, and each time<br>the transfer time increased by ca. 10 seconds.<br></div></blockquote><br><blockquote type="cite"><div> an 18 brick distributed replicated Volume with a replica 6 setting.<br></div></blockquote><br>David,<br><br>Why "replica 6"? That means you're keeping a copy of each file physically on<br>each server. So if writing the file file to one takes 10 seconds, writing<br>the file to a second takes another 10 seconds, and so on, that kind of makes<br>sense. You can't transfer a single file to two places as fast as to one.<br><br>Having more than two copies of any single file is unusual. Having more than<br>three - I'm not sure why anyone would do that for local storage.<br><br>Whit<br></div></div></span>
</blockquote>
<div>
<br>
</div>
</div>
</div>