From owner-freebsd-fs@freebsd.org Tue Apr 24 11:21:11 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8F1EAF8B957 for ; Tue, 24 Apr 2018 11:21:11 +0000 (UTC) (envelope-from zmey20000@yahoo.com) Received: from sonic307-37.consmr.mail.ne1.yahoo.com (sonic307-37.consmr.mail.ne1.yahoo.com [66.163.190.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 28D0886C76 for ; Tue, 24 Apr 2018 11:21:11 +0000 (UTC) (envelope-from zmey20000@yahoo.com) X-YMail-OSG: Tk8URDUVM1mTy_u8s7MJ23Ydn0mBy.KTvKzWClcJslyv7ifgHeY3TAmb_u4mh40 tjt3ZY4BBYExvBUdWWuvxv8YukY9mRF8OIIE6CpSC2j7Ioj2diq.sz5v6L_R5BuWePTVeZ376WYa tTjoKccWLVhaLT1ROY5c4Q34p263hUb1UFrqyfI9XASi.xh7VGFhFS2NRxr8ZcQlxeWBcsMb0iaR tCOqgXsQ7WJ7gvvUDGYgfkL0LOIQ6bTpXIVipDr4IQ_xwU19GsqNl6zI_6MCPJAS22vbujhyrzxe HRWlqGkJIesdzaYpVbbQmEz4ksTKUlkmNSPjXFG20XcDxQ.IQpgpNV3XOdK0niW59antv_8QSv_U N1TrX7dqGebLGQc9h_..Zw3d.Zn3Zc3Rx0J0ooXWaxRL2sWM.WQPcJ4NfMbAOp3tF7Fl2Yzgw2jP 0_4bErwrXI3yZx.qwtiqjUh12Q6OtE1zuhXBrfcLagWakUo1_SzPolvNHlx8Rjl_0edQ.WGEThyZ 8vHY8_LPa_WZanXmoTwUsWvk6xSdjVRLu_nhtz9yuXIqpDzg0Ye_GcNqovDd2LrGQXYu26bZAk_P Yv8lOC4ZR3juliO7GXzH9zIs9 Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ne1.yahoo.com with HTTP; Tue, 24 Apr 2018 11:21:10 +0000 Received: from athe-hcsd-peer.customers.otenet.gr (EHLO [192.168.140.13]) ([195.167.103.234]) by smtp425.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 6e0247872a84857e5fb2b1e9a0b67144; Tue, 24 Apr 2018 11:17:09 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: ctl_isc_lun_sync: Received conflicting HA LUN From: Mikhail Zakharov X-Mailer: iPhone Mail (15E216) In-Reply-To: <1524567621.9560.65.camel@inparadise.se> Date: Tue, 24 Apr 2018 14:17:07 +0300 Cc: "freebsd-fs@freebsd.org" , Mike Tancsa Content-Transfer-Encoding: quoted-printable Message-Id: References: <4cb4aa83-bd49-0c20-4e41-c11c682b0570@sentex.net> <1e1e7cd5-0797-c168-fbce-a36edc6a432e@sentex.net> <1524550160.1130.6.camel@inparadise.se> <615DFFBB-239A-4350-B961-FD10D0C9A8DD@yahoo.com> <1524567621.9560.65.camel@inparadise.se> To: karli@inparadise.se X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 11:21:11 -0000 I don=E2=80=99t think, adding a third node will add accuracy to BQ, and ther= e is no network connection involved with BQ usage. Also if both nodes have s= toped updating stamps, the system is dead. But the third node may be configu= red to handle all other issues related to any interconnections and death of B= Q itself :) WBR, Mike > 24 =D0=B0=D0=BF=D1=80. 2018 =D0=B3., =D0=B2 14:00, Karli Sj=C3=B6berg =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): >=20 >> On Tue, 2018-04-24 at 12:32 +0300, Mikhail Zakharov wrote: >> Hi Karli, >>=20 >> Thank you, I=E2=80=99m just exploring the storage abilities of my preferr= ed >> OS - FreeBSD.=20 >>=20 >> Three nodes are preferable to choose the quorum for sure, but my idea >> was not to establish contacts between nodes. Instead of it, BQ uses a >> small partition for the =E2=80=9Cquorum=E2=80=9D on the same space where d= ata volume >> is located.=20 >=20 > Yes, of course. But there=C2=B4s nothing you from having three nodes > connected to the same partition and being able to make more accurate > choices on when to take over? >=20 > If one node stops updating stamps, take over. If two nodes stops > updating, then the problem is likely network-related and _must not_ > take over to avoid split brain. Something like that? >=20 > /K >=20 >> And if a node looses access to the quorum it means, it looses access >> to the data volume too. Now, BQ runs on both nodes and both BQ >> instances write stamps to the quorum partition. If for any reason BQ >> on one node detects, the other node stops updating it=E2=80=99s stamps, i= t >> performs failover procedure. It=E2=80=99s quite a questionable, rude way,= I >> can agree, and that=E2=80=99s why I always write a warning to use the Bea= ST >> for testing only purposes.=20 >>=20 >> Best regards, >> Mike >>=20 >>> 24 =D0=B0=D0=BF=D1=80. 2018 =D0=B3., =D0=B2 9:09, Karli Sj=C3=B6berg >>> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): >>>=20 >>>>> On Mon, 2018-04-23 at 13:11 -0400, Mike Tancsa wrote: >>>>> On 4/23/2018 12:59 PM, Mikhail Zakharov wrote: >>>>>=20 >>>>> Hello Mike, >>>>>=20 >>>>> Thank you for your interest to my paper. I appreciate it very >>>>> much! >>>>> Your error may be a consequence of the initial HA >>>>> misconfiguration. >>>>> What is in your /boot/loader.conf? Although the described >>>>> config is >>>>> quite simple, I can recheck the instruction in my paper in a >>>>> couple >>>>> of weeks only, unfortunately I=E2=80=99m on vacation right now. >>>=20 >>> [snip] >>>=20 >>> I read your articles on CTL HA, BQ and BeaST, and just wanted to >>> say >>> they are amazing, good job! >>>=20 >>> One thing I=C2=B4m wondering about though is if you can claim HA with >>> just >>> two nodes, usually you need at least three, where the third is a >>> tie- >>> breaker. Otherwise with your current setup, both systems may loose >>> contact with each other while both still being powered on, leading >>> to >>> potential split brain situations. What are your thoughts about >>> that? >>>=20 >>> /K >>=20