02.08.2018 18:40, Ashish Pandey пишет:


I think it should be rephrased a little bit -

"When one brick is up: Fail FOP with EIO."
should be
"When only one brick is up out of 3 bricks: Fail FOP with EIO."

So we have 2 data bricks and one thin arbiter brick. Out of these 3 bricks if only one brick is UP then we will fail IO.

---
Ashish


Hello!

Thank you!

This is what we need :-)


------------------------------------------------------------------------
*From: *"Dmitry Melekhov" <d...@belkam.com>
*To: *gluster-users@gluster.org, atumb...@redhat.com
*Sent: *Thursday, August 2, 2018 4:59:41 PM
*Subject: *Re: [Gluster-users] thin arbiter vs standard arbiter

01.08.2018 22:04, Amar Tumballi пишет:

    This recently added document talks about some of the
    technicalities of the feature:

    
https://docs.gluster.org/en/latest/Administrator%20Guide/Thin-Arbiter-Volumes/

    Please go through and see if it answers your questions.

    -Amar


Hello!

I have question:

Manual says:


"When one brick is up: Fail FOP with EIO."

So, if we have 2 nodes with thin arbiter and only one node is up, i.e. second node is down for some reason, then I/O will be stopped.
Any reasons to have two nodes then?

Could you tell me is manual right here or it is misprint?

Thank you!




    On Wed, Aug 1, 2018 at 11:09 PM, wkmail <wkm...@bneit.com
    <mailto:wkm...@bneit.com>> wrote:

        I see mentions of thin arbiter in the 4.x notes and I am
        intrigued.

        As I understand it, the thin arbiter volume is

        a) receives its data on an async basis (thus it can be on a
        slower link). Thus gluster isn't waiting around to verify if
        it actually got the data.

        b) is only consulted in situations where Gluster needs that
        third vote, otherwise it is not consulted.

        c) Performance should therefore be better because Gluster is
        only seriously talking to 2 nodes instead of 3 nodes (as in
        normal arbiter or rep 3)

        Am I correct?

        If so, is thin arbiter ready for production or at least use on
        non-critical workloads?

        How safe is it for VMs images (and/or VMs with sharding)?

        How much faster is thin arbiter setup over a normal arbiter
        given that the normal data only really sees the metadata?

        In a degraded situation (i.e. loss of one real node), would
        having a thin arbiter on a slow link be problematic until
        everything is healed and returned to normal?

        Sincerely,

        -wk

        _______________________________________________
        Gluster-users mailing list
        Gluster-users@gluster.org <mailto:Gluster-users@gluster.org>
        https://lists.gluster.org/mailman/listinfo/gluster-users





-- Amar Tumballi (amarts)


    _______________________________________________
    Gluster-users mailing list
    Gluster-users@gluster.org
    https://lists.gluster.org/mailman/listinfo/gluster-users



_______________________________________________
Gluster-users mailing list
Gluster-users@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-users


_______________________________________________
Gluster-users mailing list
Gluster-users@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-users

Reply via email to