From owner-freebsd-fs@FreeBSD.ORG Wed Oct 1 13:52:21 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 22A3AD1E for ; Wed, 1 Oct 2014 13:52:21 +0000 (UTC) Received: from mx1.internetx.com (mx1.internetx.com [62.116.129.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9E5229CA for ; Wed, 1 Oct 2014 13:52:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mx1.internetx.com (Postfix) with ESMTP id B77651472001; Wed, 1 Oct 2014 15:52:16 +0200 (CEST) X-Virus-Scanned: InterNetX GmbH amavisd-new at ix-mailer.internetx.de Received: from mx1.internetx.com ([62.116.129.39]) by localhost (ix-mailer.internetx.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+81oNmjKsP0; Wed, 1 Oct 2014 15:52:14 +0200 (CEST) Received: from [192.168.100.26] (pizza.internetx.de [62.116.129.3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.internetx.com (Postfix) with ESMTPSA id 179534C4C9BA; Wed, 1 Oct 2014 15:52:14 +0200 (CEST) Message-ID: <542C0710.3020402@internetx.com> Date: Wed, 01 Oct 2014 15:52:16 +0200 From: InterNetX - Juergen Gotteswinter Reply-To: jg@internetx.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: George Kontostanos , freebsd-fs@freebsd.org Subject: Re: HAST with broken HDD References: <542BC135.1070906@Skynet.be> <542BDDB3.8080805@internetx.com> <542BF853.3040604@internetx.com> <542C019E.2080702@internetx.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 13:52:21 -0000 Am 01.10.2014 um 15:49 schrieb George Kontostanos: > On Wed, Oct 1, 2014 at 4:29 PM, InterNetX - Juergen Gotteswinter > > wrote: > > Am 01.10.2014 um 15:06 schrieb George Kontostanos: > > > > > > On Wed, Oct 1, 2014 at 3:49 PM, InterNetX - Juergen Gotteswinter > > >> wrote: > > > > Am 01.10.2014 um 14:28 schrieb George Kontostanos: > > > > > > On Wed, Oct 1, 2014 at 1:55 PM, InterNetX - Juergen Gotteswinter > > > > > > >>> wrote: > > > > > > Am 01.10.2014 um 10:54 schrieb JF-Bogaerts: > > > > Hello, > > > > I'm preparing a HA NAS solution using HAST. > > > > I'm wondering what will happen if one of disks of the > > primary node will > > > > fail or become erratic. > > > > > > > > Thx, > > > > Jean-François Bogaerts > > > > > > nothing. if you are using zfs on top of hast zfs wont even > > take notice > > > about the disk failure. > > > > > > as long as the write operation was sucessfull on one of the 2 > > nodes, > > > hast doesnt notify the ontop layers about io errors. > > > > > > interesting concept, took me some time to deal with this. > > > > > > > > > Are you saying that the pool will appear to be optimal even with a bad > > > drive? > > > > > > > > > > https://forums.freebsd.org/viewtopic.php?&t=24786 > > > > > > > > It appears that this is actually the case. And it is very disturbing, > > meaning that a drive failure goes unnoticed. In my case I completely > > removed the second disk on the primary node and a zpool status showed > > absolutely no problem. Scrubbing the pool began resilvering which > > indicates that there is actually something wrong! > > > right. lets go further and think how zfs works regarding direct hardware > / disk access. theres a layer between which always says ey, everthing is > fine. no more need for pool scrubbing, since hastd wont tell if anything > is wrong :D > > > Correct, ZFS needs direct access and any layer in between might end up a > disaster!!! > > Which means that practically HAST should only be used in UFS > environments backed by a hardware controller. In that case, HAST will > not notice again anything (unless you loose the controller) but at least > you will know that you need to replace a disk, by monitoring the > controller status. > imho this should be included at least as a notice/warning in the hastd manpage, afaik theres no real warning about such problems with the hastd/zfs combo. but lots of howtos are out there describing exactly such setups. sad, since the comparable piece on linux - drbd - is handling io errors fine. the upper layers get notified like it should be imho