Re: Can I bring a development idea to Dev's attention?

Ed W <lists@xxxxxxxxxxxxxx> · Wed, 06 Oct 2010 16:05:47 +0100



    Any news? Wed latest seems to have been and gone?

    
    I think some kind of optimistic locking is the kind of thing which
    pushes Gluster into the high performance bracket (without needing
    40GB cards, which when you think about it kind of ends up creating
    just one big NUMA machine rather than a cluster setup)

    
    If the kernel NLM can do this satisfactorily then seems like things
    get even better?

    
    Cheers

    
    Ed W

    
    On 26/09/2010 03:02, Craig Carl wrote:
    
      
      Ed - 

            I'll follow up on your request with engineering and
        professional services, can we get back to you Wednesday latest?

          
            Thanks, 

              
              Craig

              
              --

              Craig Carl

              
                                      Sales Engineer; Gluster, Inc.
                                        

                                        Cell - (408)
                                            829-9953
                                        (California, USA)

                                        Office - (408)
                                            770-1884

                                        Gtalk - craig.carl@xxxxxxxxx

                                        Twitter - @gluster

                                        Installing


                                              Gluster Storage Platform,
                                              the movie!

                                          http://rackerhacker.com/2010/08/11/one-month-with-glusterfs-in-production/

                                      
From: "Ed W" <lists@xxxxxxxxxxxxxx>

        To: gluster-devel@xxxxxxxxxx

        Sent: Saturday, September 25, 2010 5:35:21 PM

        Subject: Re: Can I bring a development
        idea to Dev's attention?

        
          Does someone from Gluster like to contact me with a
        "reasonable" offer 

        for sponsoring some kind of "optimistic cache" feature, with a
        specific 

        view to optimising the NUFA server side replication
        architecture?

        
        I would specifically like to optimise the case that you have a
        flat 

        namespace on the server (master/master filesharing), but you
        optimise 

        the applications in such a way that the applications running on
        each 

        brick (NUFA) only touch a subset of all files (in general).  eg
        a 

        mailserver with a flat filesystem, but users are proxied so that
        they 

        generally touch only a specific server, or a webserver with a
        flat 

        namespace where a proxy points specific domains to be served by
        specific 

        servers?

        
        In this case I would like to see a specific brick realise that
        it's 

        predominantly the reader/write for a subset of all files and
        optimise 

        it's access at the expense of other bricks which need to access
        the same 

        files (ie I don't just want to turn up the writeback cache, I
        want cache 

        coherency across the entire cluster).  I would accept that
        random 

        read/writes to random bricks would be slower, in return for the
        

        optimisation that reads/writes would be faster *if* the clients
        optimise 

        themselves to *prefer* to touch specific bricks (ie NUFA).  Such
        an 

        optimisation should not be set in stone of course, if the
        activity on a 

        subdirectory generally seems to move across to another brick
        then that 

        brick should eventually optimise it's read/write performance (at
        the 

        expense that another brick's access now becomes slower to that
        same 

        subset of files.)

        
        Anyone care to quote on this?  Seems like it's a popular
        performance 

        issue on the mailing list and with some optimisation later it
        also seems 

        like the basis for cross datacenter replication?

        
        Thanks

        
        Ed W

        
        _______________________________________________

        Gluster-devel mailing list

        Gluster-devel@xxxxxxxxxx

        http://lists.nongnu.org/mailman/listinfo/gluster-devel