From owner-freebsd-fs@FreeBSD.ORG Fri Mar 18 21:11:20 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B518E106564A for ; Fri, 18 Mar 2011 21:11:20 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6F89D8FC18 for ; Fri, 18 Mar 2011 21:11:20 +0000 (UTC) Received: by gyg13 with SMTP id 13so1995153gyg.13 for ; Fri, 18 Mar 2011 14:11:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cA48Hq96JCZeCG4QagcznGp4nw788fBRmhZ9YcXB1Ro=; b=hb+a/lfYCkhHKZNC6tCpGjBwdNPdxgcD5OhaioSq35uc0K/hkGZkCIVVTiEPrDgpVc 3tp2AsaSMZqMtkAWDg8eR3BppsbmQGdEvlACK2ndO3hjQmeTw1PNpF7Q/39G2XOz/C9N IaGHBRQJ6G3TnuybyKXpwI1GA90qJ4meNpL1s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YIzuSrrs2IxEOS2OsO4TTcM6r7DDWUL9ztPCNpQewosFJNF+nfT52VPUdLxR41F6a1 1mGWjlfRSdkMouNoBppophvl/fcOihaIxwX0q5wZhytxLd9f253nAReCzRortpvB8FBO UmddquoKX86Qsaz+5pK4DVgFjmFQVhFvwf8gw= MIME-Version: 1.0 Received: by 10.90.126.19 with SMTP id y19mr1668392agc.114.1300482679617; Fri, 18 Mar 2011 14:11:19 -0700 (PDT) Received: by 10.90.83.18 with HTTP; Fri, 18 Mar 2011 14:11:19 -0700 (PDT) In-Reply-To: <8662rgrvp8.fsf@kopusha.home.net> References: <8662rgrvp8.fsf@kopusha.home.net> Date: Fri, 18 Mar 2011 14:11:19 -0700 Message-ID: From: Freddie Cash To: Mikolaj Golub Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: HAST + ZFS causes system to shutdown uncleanly? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 21:11:20 -0000 On Fri, Mar 18, 2011 at 1:59 PM, Mikolaj Golub wr= ote: > On Thu, 17 Mar 2011 13:42:09 -0700 Freddie Cash wrote: > =C2=A0FC> On Thu, Mar 17, 2011 at 1:36 PM, Freddie Cash wrote: > =C2=A0>> On Thu, Mar 17, 2011 at 12:32 PM, Thomas Johnson wrote: > =C2=A0>>> Has anyone else noticed issues halting a system that is configu= red with a > =C2=A0>>> ZFS filesystem on a HAST device? I am using HAST to replicate a= ZFS > =C2=A0>>> filesystem between two ESXi virtual machines (trying to emulate= our > =C2=A0>>> production systems in a test environment) and I've noticed that= the system > =C2=A0>>> doesn't seem to shutdown completely in this arrangement (hangs = after "" > =C2=A0>>> message). I did some poking around and learned that if I unmoun= t my zfs > =C2=A0>>> filesystems before shutdown, the shutdown finishes cleanly. Mud= dling my way > =C2=A0>>> through the rc scripts, it looks like hastd is killed fairly ea= rly on in the > =C2=A0>>> shutdown sequence. Presumably this is preventing the system fro= m > =C2=A0>>> syncing/unmounting the ZFS mounts, causing the shutdown to hang= . > =C2=A0>>> > =C2=A0>>> Does this seem plausible? If so, any ideas on fix, besides maki= ng sure I > =C2=A0>>> 'zfs unmount -a' before shutdown? > =C2=A0>> > =C2=A0>> Does it work if you manually add "hastd" to the REQUIRE: line in= /etc/rc.d/zfs? > =C2=A0>> > =C2=A0>> Of course, that only works if you are starting zfs automatically= via > =C2=A0>> /etc/rc.conf, and not letting CARP/devd or something else manage= the > =C2=A0>> pool import process. > > =C2=A0FC> Thinking about it, perhaps we need a hook into the top of the > =C2=A0FC> hastd_stop_precmd() function in /etc/rc.d/hastd? > > =C2=A0FC> Something like "hastd_stop_args" in /etc/rc.conf where we can p= ut > =C2=A0FC> commands to be run before hastd is stopped? > > =C2=A0FC> Then it would be as simple as putting hastd_stop_args=3D"zfs un= mount -a" > =C2=A0FC> into /etc/rc.conf. > > =C2=A0FC> Or something along those lines, so that we stop any consumers o= f the > =C2=A0FC> /dev/hast/* devices before we stop the hast daemon. > > IMHO, it is not HAST job to bother with such things. We always have somet= hing > (heartbeat, carp, hastmon) to manage HAST (change role, mount fs, start > applications). This something has it own rc scripts, on startup it sets r= oles > and mounts fs (if needed) and on shutdown it should do all necessary clea= nup. Unless I'm missing something here, this has nothing to do with shutting off the master node in a HAST setup, where the ZFS pool is mounted, when the slave node is already offline. As far as CARP, devd, heartbeat, etc are concerned, everything is up and running correctly. No need to unmount the pool, as it's not switching to slave mode. Or, are you suggesting that part of the "shutdown procedure" would be to switch it to slave first, then shutdown? --=20 Freddie Cash fjwcash@gmail.com