From owner-freebsd-fs@FreeBSD.ORG Wed Oct 1 13:49:06 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 38C15B29 for ; Wed, 1 Oct 2014 13:49:06 +0000 (UTC) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B40A4903 for ; Wed, 1 Oct 2014 13:49:05 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id y10so517302wgg.15 for ; Wed, 01 Oct 2014 06:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=wpPSLOAY4SXyGk3rEet1hcIMpJu7vSh9aYL3mQpmCjs=; b=q+3GheLJoecchWVSTj/8rmScUKAQpXsk9efqax16tM9pMkcRirB2tshxYmG18qjpZp nAvBf0nEAVlk1dxX+seoe/LYvA7ehZKTrItQZ7nL5gl/PSJHshVkgdqU6bppNPTwvVwf dXYkq0twJ+VRSanyZp11T+/tzIdEudd9DwuQ0FBYVqnScGfV9w8vsW75jUN993gVsGXq yXbReVs+F9i9KiOEkQaqKfZk7oVesugps9tPgvufUAJEEeiHlMLgcY02xf9KGj5CF9Pr 4tLAWzH3PX/y4EwEyKUCoNlVfwM5G3eANCkNFzB8vWE1jNFZhu/uOKLuN+mhF2jky412 lJdg== MIME-Version: 1.0 X-Received: by 10.194.76.97 with SMTP id j1mr60843523wjw.40.1412171343916; Wed, 01 Oct 2014 06:49:03 -0700 (PDT) Received: by 10.27.137.130 with HTTP; Wed, 1 Oct 2014 06:49:03 -0700 (PDT) In-Reply-To: <542C019E.2080702@internetx.com> References: <542BC135.1070906@Skynet.be> <542BDDB3.8080805@internetx.com> <542BF853.3040604@internetx.com> <542C019E.2080702@internetx.com> Date: Wed, 1 Oct 2014 16:49:03 +0300 Message-ID: Subject: Re: HAST with broken HDD From: George Kontostanos To: jg@internetx.com, freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 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:49:06 -0000 On Wed, Oct 1, 2014 at 4:29 PM, InterNetX - Juergen Gotteswinter < jg@internetx.com> 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=C3=A7ois 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=3D24786 > > > > > > > > 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.