dont forget to set : option read-subvolume BRICKNAME in your AFR config, that'll improve your read performance significantly. At 11:06 AM 1/23/2009, Evan wrote: >Ideal what I'm trying to accomplish is to have multiple samba >servers connected with a 1.544Mbps pipe stay in sync with each >other. So its important for me to be able to have near really disk >access speeds when reading and writing to the local gluster Node in >the AFR group but as far as getting the data propagated out to the >other nodes I know the 1.544Mbps pipe can't keep up so I'll take the >fastest I can get as long as it doesn't affect the local performance >(which is what I am seeing). > > > >On Fri, Jan 23, 2009 at 10:56 AM, Keith Freedman ><<mailto:freedman at freeformit.com>freedman at freeformit.com> wrote: >At 10:18 AM 1/23/2009, Evan wrote: >I added the following to the bottom of my spec file: > >volume writebehind > type performance/write-behind > option aggregate-size 10MB # default is 0bytes > option flush-behind off # default is 'off' > subvolumes afr >end-volume > >which gives me the following results when making a 10MB file ># time dd if=/dev/zero of=/tmp/disktest count=10240 bs=1024 >10240+0 records in >10240+0 records out >10485760 bytes (10 MB) copied, 0.173179 s, 60.5 MB/s > >real 0m0.183s >user 0m0.000s >sys 0m0.204s > ># time dd if=/dev/zero of=/mnt/gluster/disktest count=10240 bs=1024 >10240+0 records in >10240+0 records out >10485760 bytes (10 MB) copied, 5.50861 s, 1.9 MB/s > >real 0m5.720s >user 0m0.000s >sys 0m0.060s > >Although this is better than I had before is there anyway to have >gluster write the data to the localBrick and then sync/afr in the >background so I could expect to see something closer to the 60 MB/s >I see when writing to the local disk directly? > > >what you really want is a delayed replication. I've asked for this >in this mailing list recently, and was told that it's something >they've considered (more as a DR feature than an HA feature), but >it's not currently on the list of priorities. > >The issue, as I see it, is if it's an HA feature, then you really >need to insure that the data is replicated before you let your >application think the data is written. If the replication was >delayed, and the server went down, the data is lost forever. This >is bad for HA. >if it's a DR feature, then you're probably ok, because usually >disaster recovery scenarios can probably withstand some data loss, >and you're more interested in a point-in-time snapshot of the data. > >FUSE is a problem, and TCP/IP is a problem with much overhead and >large blocksizes. > >Ideally, glusters write-behind would be smart enough to aggregate >smaller blocks of data into a large write. I think this would solve >a lot of the problem you're having in your tests. > >Thanks > > >aghavendra G ><<mailto:raghavendra at zresearch.com><mailto:raghavendra at zresearch.com>raghavendra at zresearch.com> >wrote: >above afr with afr as a subvolume > >On Fri, Jan 23, 2009 at 12:59 AM, Evan ><_<mailto:Gluster at devnada.com><mailto:Gluster at devnada.com>Gluster at devnada.com> >wrote: >Where should I put the write-behind translator? >Just above afr with afr as a subvolume? Or should I put it just >above my localBrick volume and below afr? > > >Here is the output using /dev/zero: ># time dd if=/dev/zero of=/mnt/gluster/disktest count=1024 bs=1024 > >1024+0 records in >1024+0 records out >1048576 bytes (1.0 MB) copied, 1.90119 s, 552 kB/s > >real 0m2.098s >user 0m0.000s >sys 0m0.016s > ># time dd if=/dev/zero of=/tmp/disktest count=1024 bs=1024 > >1024+0 records in >1024+0 records out >1048576 bytes (1.0 MB) copied, 0.0195388 s, 53.7 MB/s > >real 0m0.026s >user 0m0.000s >sys 0m0.028s > > >Thanks > > >On Thu, Jan 22, 2009 at 12:52 PM, Anand Avati ><<mailto:avati at zresearch.com><mailto:avati at zresearch.com>avati at zresearch.com> >wrote: >Do you have write-behind loaded on the client side? For IO testing, >use /dev/zero instead of /dev/urandom. > >avati > >On Fri, Jan 23, 2009 at 2:14 AM, Evan ><_<mailto:Gluster at devnada.com><mailto:Gluster at devnada.com>Gluster at devnada.com> >wrote: > > I have a 2 node single process AFR setup with 1.544Mbps bandwidth between > > the 2 nodes. When I write a 1MB file to the gluster share it > seems to AFR to > > the other node in real time killing my disk IO speeds on the gluster mount > > point. Is there anyway to fix this? Ideally I would like to see near real > > disk IO speeds from/to the local gluster mount point and let the afr play > > catch up in the background as the bandwidth becomes available. > > > > Gluster Spec File (same on both nodes) > <<http://pastebin.com/m58dc49d4>http://pastebin.com/m58dc49d4>http://pastebin.com/m58dc49d4 > > > IO speed tests: > > # time dd if=/dev/urandom of=/mnt/gluster/disktest count=1024 bs=1024 > > 1024+0 records in > > 1024+0 records out > > 1048576 bytes (1.0 MB) copied, 8.34701 s, 126 kB/s > > > > real 0m8.547s > > user 0m0.000s > > sys 0m0.372s > > > > # time dd if=/dev/urandom of=/tmp/disktest count=1024 bs=1024 > > 1024+0 records in > > 1024+0 records out > > 1048576 bytes (1.0 MB) copied, 0.253865 s, 4.1 MB/s > > > > real 0m0.259s > > user 0m0.000s > > sys 0m0.284s > > > > > > Thanks > > > > _______________________________________________ > > Gluster-users mailing list > > > <mailto:Gluster-users at gluster.org><mailto:Gluster-users at gluster.org>Gluster-users at gluster.org > > > http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users > > > > > > > >_______________________________________________ >Gluster-users mailing list ><mailto:Gluster-users at gluster.org><mailto:Gluster-users at gluster.org>Gluster-users at gluster.org > >http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users > > > > >-- >Raghavendra G > > >_______________________________________________ >Gluster-users mailing list ><mailto:Gluster-users at gluster.org>Gluster-users at gluster.org >http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users > >
